> ## Documentation Index
> Fetch the complete documentation index at: https://docs.postqueen.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# System Requirements
> Hardware, services and network requirements for self-hosting PostQueen
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](/installation/overview) points you at the right guide.
## Hardware
Recommended starting point for a small team (≤ 20 users):
| Component | Supported floor | Recommended |
| --------- | ---------------------------- | ------------------------------------- |
| CPU | 2 vCPU | 4 vCPU |
| RAM | 2 GB (all-in-one, light use) | 8 GB |
| Disk | 20 GB | 50 GB + persistent volume for uploads |
The official Docker Compose has been tested on a 2 GB / 2 vCPU Ubuntu VM running everything on
one host (see [Docker Compose](/installation/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:
```bash theme={"system"}
NODE_OPTIONS="--max-old-space-size=4096" pnpm install
```
## Recommended install path
The canonical self-host setup is the official Docker Compose repo.
Pre-wired PostQueen + Postgres + Redis + Temporal. The fastest way to a working install.
| Your situation | Guide |
| ---------------------------------- | ---------------------------------------------------- |
| Looking around on your own machine | [Try her locally](/installation/quickstart-local) |
| A real install on your own domain | [Deploy to a server](/installation/production) |
| Building from source | [Development Environment](/installation/development) |
| Running Kubernetes instead | [Helm](/installation/kubernetes-helm) |
## Required services
Three are required. The fourth is optional, because local disk works.
| Service | Minimum version |
| -------------- | -------------------------------------------------------------------------------------------------------------------- |
| PostgreSQL | 14 |
| Redis | 6 |
| Temporal | bundled with official docker-compose; required |
| Object storage | Optional: local filesystem works (`STORAGE_PROVIDER=local`), Cloudflare R2 supported (`STORAGE_PROVIDER=cloudflare`) |
The official [docker-compose](https://github.com/GkhanKINAY/postqueen-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
| Service | Port | When |
| ------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------ |
| PostQueen container (bundled FE + BE) | `5000` | Official Docker image (`ghcr.io/gkhankinay/postqueen-app`), exposed for you to map. The bundled compose maps host `4007:5000`. |
| Backend (Nest) | `3000` | Running from source (`pnpm dev` / `pnpm start`). Override via `PORT`. |
| Frontend (Next.js) | `4200` | Running from source. |
| Temporal frontend | `7233` | gRPC; both modes. |
| Temporal UI | `8080` | If bundled compose is used. |
## 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](/configuration/uploads).
## 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](/installation/domain-and-https).
## Next steps
The whole stack on your own machine in about five minutes
An empty virtual machine to your own domain, with HTTPS
Every setting she reads, and what happens when you leave one out
Which volumes hold data you cannot rebuild, and how to restore one