Skip to main content
A dev container is a development environment described in the repository itself. Your editor reads that description, builds a container with the right Node version and the right tools, and opens the code inside it. You get a working setup without installing anything on your own machine beyond Docker and an editor. This is the same environment as Development Environment, set up for you instead of by you. Pick whichever you prefer.
This is for changing PostQueen, not for running her. To self-host, use Docker Compose.

​
What you get

The container brings up its own PostgreSQL, Redis and Temporal, and installs dependencies and the database schema on first start. Nothing is published to your host except the app itself, so it runs happily alongside an existing PostQueen install on the same machine.
Give Docker at least 5 GB. The backend’s watch build and Temporal’s Elasticsearch are both hungry, and on less the build gets killed part way through. In Docker Desktop the setting is under Settings → Resources. If you are also running a PostQueen install on the same machine, stop it first or raise the limit further.

​
Set it up

1

Install what you need

Docker Desktop and VS Code, plus the Dev Containers extension.
2

Clone and open

3

Reopen in the container

VS Code offers Reopen in Container in the corner. If you miss it, open the command palette and run Dev Containers: Reopen in Container.The first build takes a few minutes. It pulls images, installs dependencies and creates the database schema, and you can watch it in the terminal panel.
4

Run her

In the container’s terminal:
Open http://localhost:4200. VS Code forwards the port for you.
dev-backend runs the frontend and backend, which is what you want most of the time. pnpm run dev adds the browser extension build on top.

​
Good to know

The container’s database, Redis and Temporal are private to it. They have generated names and publish nothing to your host, so an existing Docker Compose install keeps running untouched on port 4007.
On first start, if there is no .env, one is created from .env.example with the database addresses rewritten to the container’s service names.An existing .env is left alone. It cannot break the container either, because the connection strings and the URL variables are set in the container’s own environment, and the dev scripts load .env without overriding what is already there. So a file tuned to your host, for example one pointing NEXT_PUBLIC_BACKEND_URL at a proxy, keeps working on your host and is ignored in here.
Use Dev Containers: Rebuild Container in VS Code, or from the command line:
That re-runs the whole first-start sequence. Plain devcontainer up reuses the existing container and skips it.
.devcontainer/devcontainer.json, .devcontainer/docker-compose.yml and .devcontainer/post-create.sh in the app repository. Edit them if you want different tools, then rebuild.

​
Next Steps

Add a provider

What a new social network needs on the backend and the frontend

Developer guide

How the codebase is organised and how to contribute