Let enterprise customers bring their own destination
Enterprise procurement asks for it constantly: 'we need your events delivered to our infrastructure, on our credentials, audited on our side.' Ship the feature instead of saying no.
The problem
Enterprise sales cycles stall on a familiar question: 'Where does our data live, and who controls it?' Procurement teams want events delivered into customer-owned infrastructure, their bucket, their warehouse, their queue, using credentials they manage and that they can revoke. They want an audit trail they can subpoena. They don't want to depend on your storage decisions for data that's regulated on their side.
Saying 'we'll add it to the roadmap' is a six-figure deal-killer when the alternative vendor said 'yes.' Saying 'sure, we'll build a one-off integration for you' commits an engineering quarter and creates a precedent that compounds with every subsequent enterprise customer.
The right answer is to make 'bring your own destination' a productized capability, same code path for every customer, no bespoke integration work, full compliance posture on day one.
How Pushrail solves it
Pushrail makes BYO-destination a first-class product feature. The customer authorizes Pushrail to write to their bucket, queue, warehouse, or database using their own credentials. Pushrail stores the credentials encrypted at rest, scopes them to the customer's destination, and writes events with the customer's identity, not yours.
Tenant isolation is enforced at every layer: the credential belongs to one customer; the destination configuration belongs to one customer; the audit log entries are scoped to one customer. A different customer in the same Pushrail tenant cannot see, use, or trigger writes against another customer's destination.
Audit-trail expectations are built in. Every config change, credential rotation, and delivery attempt is logged with timestamps, actor, and outcome, exportable on demand for the customer's compliance review.
What you ship to your customers
- Enterprise customers configure their own destination with their own credentials.
- Per-customer credential storage with AES-256 encryption at rest and dashboard-driven rotation.
- Tenant + sub-tenant isolation enforced at the API and the storage layer, a customer cannot see another customer's destinations.
- Audit log entries for every config change, credential rotation, and delivery attempt, exportable on demand.
- Egress IP allowlisting, Pushrail's outbound IPs are stable and published, so customers can lock their bucket / firewall to known sources.
What this replaces
- Six-figure deal stalls on 'where does our data go?' procurement asks.
- Bespoke per-customer integration code committed for a single contract.
- Compliance documentation work that has to be redone for every enterprise customer.
- Manual credential-rotation runbooks tracked in spreadsheets.
Concrete walkthrough
- 1. The customer's IT team creates a Pushrail-scoped principal in their environment, an IAM role, a service account, a database user, or whatever the destination requires.
- 2. They grant write-only access to one specific bucket, dataset, or topic. Nothing more.
- 3. In your dashboard (or the embedded portal), the customer creates a new destination, pastes the credential, and tests it.
- 4. Pushrail starts writing events under the customer's identity. The audit log records every delivery attempt with the customer's principal as the actor.
- 5. If the customer rotates the credential, they update it in the dashboard. In-flight deliveries drain on the old creds; new deliveries pick up the new ones with no downtime.
Destinations this uses
Deliver events as NDJSON files into a customer-owned S3 bucket, batched, partitioned, and idempotent.
Stream batched NDJSON events into a customer-owned GCS bucket, same delivery model as S3, on GCP.
Batched NDJSON event delivery into a customer-owned Azure Storage container, parity with S3 and GCS.
Continuous ingest into a customer-owned Snowflake table via Snowpipe-style staging.
Related use cases
Stop building one-off CSV exports, let customers stream events into their own warehouse, lake, or queue.
Stream product events into your customers' BigQuery, Snowflake, or ClickHouse, same canonical event, different destination.
Drop an embedded portal into your app where customers configure their own destinations, without building the portal yourself.
Frequently asked questions
What does 'bring your own destination' mean?
It lets each customer point your product's events at infrastructure they own, their bucket, warehouse, queue, or database, using credentials they manage and can revoke, instead of depending on your storage decisions for data that's regulated on their side.
Whose credentials write the data, and how are they stored?
The customer's. Pushrail stores the credential encrypted at rest with AES-256, scopes it to that customer's destination, and writes events under the customer's identity, not yours. Rotations are dashboard-driven, in-flight deliveries drain on the old credential while new ones pick up the new one.
How is one customer's destination isolated from another's?
Tenant and sub-tenant isolation is enforced at the API and storage layers: the credential, the destination configuration, and the audit log entries are each scoped to one customer. A different customer in the same Pushrail tenant cannot see, use, or trigger writes against another customer's destination.
Can a customer lock their infrastructure to Pushrail's traffic?
Yes. Pushrail's outbound egress IPs are stable and published, so customers can allowlist their bucket or firewall to those known sources.
Let enterprise customers bring their own destination
Sandbox is open. No credit card.