Deployment guide · Customer network
Keep the database private. Run the worker where the data lives.
A Salesforce mirror does not need inbound access to the destination database. A customer-network worker can run in the VPC, private subnet, or on-premises environment that already holds the database, then establish the approved outbound connections it needs.
Start with the network boundary you already trust.
The point of a customer-network worker is not to make a system more complicated. It is to avoid adding a public inbound exception for a database that should remain private. The worker is placed where it can reach the local relational database over the existing private network.
Control-plane communication and source CRM access should be explicitly allowed outbound destinations. Keep the database listener limited to the worker’s normal local network path rather than exposing it to the public internet.
Place the worker like any other integration service.
Run it in the same operational environment your team already knows: a container platform, virtual machine, or a managed runtime with controlled egress. Give it a small, clear identity and only the network access it needs. The worker should be independently restartable and should not compete with your customer-facing service for database connections.
For high availability, use an active worker model with durable state rather than multiple consumers accidentally applying the same stream without coordination. The exact runtime topology depends on your availability target, but the recovery design—idempotent writes and a durable replay checkpoint—remains the same.
Keep source and destination credentials scoped.
Use a Salesforce integration user with the minimum object and field permissions necessary. Store its credentials and the database connection details in the secret manager your platform team already operates. Rotate them through a documented procedure and test that the worker fails visibly, rather than silently falling behind.
Salesforce identity: dedicated integration user with only the mapped data access.
Database identity: a scoped database user with only the mirror-schema permissions.
Secret storage: use the environment’s managed secret facility, never a checked-in config file.
Network rules: allow only the worker’s outbound destinations and private database path.
Give the worker normal production observability.
A private deployment still needs the same operational answers as a managed one: is it alive, what is the current event lag, which records failed, how old is the replay checkpoint, and did the last reconciliation pass? Send those signals into the monitoring system the on-call team already uses.
Test restarts, secret rotation, temporary egress loss, and a reconciliation repair in a non-production environment. A deployment guide is only useful if recovery has been exercised before an incident requires it.
Deployment checklist
Choose the runtime: container, VM, or managed service that your team can patch and observe.
Approve egress: source CRM and control-plane destinations only; no public database ingress.
Use private database access: scoped database user, TLS where appropriate, and a dedicated schema.
Persist progress: make replay state durable across worker restarts and deployments.
Practice recovery: restore connectivity, replay safely, and reconcile the result.
Need a private deployment path?
Bring your network diagram and destination database constraints. We’ll help scope the worker and the minimum egress it needs.