Skip to main content
Four vCPU, 8 GB of RAM and 50 GB of disk is the recommended starting point for a team of up to 20 people. She also needs PostgreSQL, Redis and Temporal. The rest of this page is the detail: exact floors, default ports, and what has to be reachable through your firewall.
Here to get her running rather than to size a server? Self-Hosting Overview points you at the right guide.

​
Hardware

Recommended starting point for a small team (≤ 20 users):
The official Docker Compose has been tested on a 2 GB / 2 vCPU Ubuntu VM running everything on one host (see Docker Compose). That works for a single-user install with occasional posting, but leaves no headroom. Once you have multiple users, scheduled workflows, or external Postgres/Redis on the same host, plan for 4 GB or more.
The build step (pnpm install / pnpm build from source) is the most memory-hungry part and can OOM on 2 GB VMs. Bump the Node heap if it fails:
The canonical self-host setup is the official Docker Compose repo.

postqueen-docker-compose

Pre-wired PostQueen + Postgres + Redis + Temporal. The fastest way to a working install.

​
Required services

Three are required. The fourth is optional, because local disk works.
The official docker-compose ships Postgres, Redis, and Temporal pre-wired. If you are running them externally, point PostQueen at them via DATABASE_URL, REDIS_URL, and TEMPORAL_ADDRESS.

​
Default ports

​
Filesystem

Uploaded media needs somewhere that survives a container being replaced. On the official image that is a volume mounted at /uploads, which the Compose file already sets up for you. Budget disk for it, since video adds up quickly.
The choice between the local disk and object storage, and how to set either up, is on Uploads and Storage.

​
Outbound network

PostQueen initiates outbound HTTPS to every social provider you connect. Strict egress firewalls will break OAuth. Make sure the backend can reach:
  • api.twitter.com, upload.twitter.com
  • graph.facebook.com, graph.instagram.com, graph.threads.net
  • linkedin.com, api.linkedin.com
  • openapi.tiktok.com, open.tiktokapis.com
  • googleapis.com (YouTube + GMB)
  • the Mastodon instance you configure via MASTODON_URL
  • any other provider you intend to use
There is no proxy support. HTTPS_PROXY and HTTP_PROXY are not read anywhere, and provider calls go out through a dispatcher that would ignore them regardless. Behind a corporate egress proxy you need a transparent proxy or an allowlist at the network layer.

​
Inbound network

The frontend talks to the backend from the browser, so NEXT_PUBLIC_BACKEND_URL must be reachable from your users’ browsers, not just from the frontend SSR server.
A reverse proxy in front of her is the typical setup: Domain and HTTPS.

​
Next steps

Try her locally

The whole stack on your own machine in about five minutes

Deploy to a server

An empty virtual machine to your own domain, with HTTPS

Configuration reference

Every setting she reads, and what happens when you leave one out

Backups and upgrades

Which volumes hold data you cannot rebuild, and how to restore one