kubbiai

kubbi vs. the alternatives

Four common alternatives, and where kubbi differs: S3 with presigned URLs, raw webhooks with inline payloads, queues with inline messages, and rolling your own claim-check service.

S3 + presigned URLs

S3 is the closest cloud-primitive equivalent. It does encryption at rest, you can set object expiry, and presigned URLs have built-in TTL.

What kubbi adds:

  • Server-enforced burn-after-read. S3 doesn't do this natively. You would need a Lambda fired on first access to delete the object.
  • Multi-file bundling as a first-class concept. S3 packages mean an archive or a directory listing. kubbi encrypts each file individually under one claim URL.
  • An SDK shaped for agent workflows, not general object storage.
  • Defaults on, not configured per-bucket.

The marginal value is real but incremental if you already have S3 + IAM dialed in.

Raw webhook with inline payload

A common pattern: deliver the data inline in the webhook body. Two issues:

  • The payload sits in webhook delivery logs, gateway logs, and the receiver's request logs.
  • Webhooks aren't designed for large or sensitive bodies.

The fix is "thin webhooks": send an ID, let the receiver call back for the actual data. kubbi productizes that pattern with encryption, TTL, and burn semantics. Real value: you don't have to build and host the callback endpoint, manage auth on it, or write the cleanup job.

Queue with inline payload

Most queues have message size limits. SQS caps individual messages at 256 KB. Larger payloads need to be chunked, compressed, or moved out of the queue.

The "claim check" enterprise pattern handles this: put a pointer in the queue, store the blob somewhere else. kubbi is a managed claim-check service with agent-flavored ergonomics. The 256 KB cap stops mattering. Sensitive data also stops sitting in queue logs and dead-letter queues.

Building it yourself

A team comfortable with cloud primitives could replicate the core in a weekend. The skeptical view is fair. But what you would be building:

  • KMS or your own key management
  • Server-side expiry enforcement
  • Server-side burn-after-read (single-use semantics)
  • A manifest preview API for multi-file bundles
  • Audit logging
  • Rate limiting per consumer

kubbi handles all of that. The trade is convenience for predictable defaults shaped for how agents actually pass payloads.

When kubbi isn't the right fit

If you're running an all-internal pipeline on AWS with S3 + IAM dialed in, presigned URLs probably cover you. kubbi pays off when the producer and consumer are in different trust boundaries, or when burn-after-read and manifest preview as defaults are a posture you want enforced server-side. For deeper coverage, see when to use kubbi.