Public callbacks, private systems

Self-hosted automation can keep the database, queue, and worker private. Expose only the small boundary a provider must reach.

Self-hosting is often framed as a choice between a public SaaS dashboard and a service hidden behind a VPN. Integrations add a third option. OAuth providers and webhook senders need a route back to the app. The valuable state can still stay on the operator's systems.

We built the OpenReply deployment example around that idea. It uses one public HTTPS app address, private data services, and a worker that is not open to the internet.

The boundary is the callback

Self-hosting does not mean every part of a service must be open to the internet. The operator chooses what is public.

For Instagram automation, the public part is the provider callback. OAuth must return to the app. Meta must also send webhook events to it. A private VPN address cannot do either job.

One public origin, private state

OpenReply uses one HTTPS address for OAuth callbacks, webhooks, magic-link emails, invitations, and tracked redirects. One public address keeps the setup simple.

The public edge should forward only to the web process. PostgreSQL and Redis stay on the Compose network. SSH, the Docker socket, the worker, and the scheduler stay private. The app login uses an email allowlist. The edge provides TLS, rate limits, and request controls.

The worker is part of the product

The web process accepts requests, but it is only one part of the app. A BullMQ worker turns queued work into provider API calls. A scheduler keeps repeat work moving. PostgreSQL stores state. Redis carries the queue.

Treating these processes as one deployable unit makes the security boundary clear. The internet reaches the web container. The worker reaches the providers. The data services reach neither.

A deployment people can own

The companion example is small. Ansible prepares an existing Alpine VM or LXC. Docker Compose runs five services. Ansible Vault keeps secrets out of the repository. It does not require Proxmox, Pangolin, a set DNS provider, or a managed database.

This matters because a self-hosting guide should show the seams. Another operator should be able to replace the edge, host, backup target, or provider without rewriting the app deployment.

The practical default

For this kind of integration, use a small public callback surface around private state and private workers.

This lets providers reach the app while the host owner keeps the data, queue, credentials, and admin access private.

The upstream OpenReply project documents the application-level setup. The TWN Systems self-host example keeps the infrastructure side explicit: what is public, what stays private, and where an operator must make their own choice.