statica

Self-host quickstart

Run the Statica server on your own machine with Docker. Takes about ten minutes.

Prerequisites

This page covers running the Statica server (backend, frontend, PostgreSQL) on a machine you control via Docker. When you're done, all your data lives where you put it: workspaces, issues, comments, agent configuration.

Agent execution still runs through a local daemon and the AI coding tools installed on that machine — same as Cloud. Self-hosting swaps the server layer, not the execution layer.

  • Docker, with the ability to run docker compose.
  • Git, so you can pull the source.
  • A machine that can stay up — local, internal network, or a cloud host all work.
  • At least one AI coding tool installed on whichever machine will run the daemon.

1. Pull the project and start the backend

git clone https://github.com/statica-ai/statica.git
cd statica
make selfhost

make selfhost generates a .env from .env.example if one doesn't exist (with a random JWT_SECRET), pulls the official Docker images, brings up every service via docker-compose.selfhost.yml, and waits for the backend's /health endpoint to come up.

Database migrations run automatically on container startup, so version upgrades are handled the same way — pull, restart, done.

Once it's up, the frontend lives on http://localhost:3000 and the backend on http://localhost:8080.

2. Keep production safety on

The default docker-compose.selfhost.yml sets APP_ENV=production and leaves STATICA_DEV_VERIFICATION_CODE empty, so there is no fixed login code on a public instance.

Only set STATICA_DEV_VERIFICATION_CODE for local or private test automation. If a fixed code is enabled on a non-production instance, anyone who can request a code can sign in with that value. Before deploying anywhere reachable from the outside, double-check that APP_ENV is production and the dev code variable is empty.

3. Configure the email service

Without email configured, users can't receive verification codes. The server falls back to printing codes to stdout. Two delivery backends are supported.

Resend (cloud / public-internet deployments):

RESEND_API_KEY=re_xxxxxxxxxxxx
RESEND_FROM_EMAIL=noreply@yourdomain.com

SMTP relay (internal networks, on-prem). Use this when the deployment can't reach api.resend.com, or you already have an internal mail relay. SMTP_HOST takes priority over Resend when both are set.

SMTP_HOST=smtp.internal.example.com
SMTP_PORT=587
SMTP_USERNAME=statica
SMTP_PASSWORD=...
RESEND_FROM_EMAIL=noreply@yourdomain.com

Restart the backend container after editing the env file: docker compose -f docker-compose.selfhost.yml restart backend.

4. First login and workspace

Open http://localhost:3000, enter your email, and grab the verification code — from your email provider if configured, otherwise from the backend container's stdout. Log in and create your first workspace.

5. Point the CLI at your own server

Install the CLI the same way as in the Cloud quickstart. Then use the self-host variant of setup:

statica setup self-host --server-url http://<your-server>:8080 --app-url http://<your-server>:3000

If everything is on a single local machine, plain statica setup self-host defaults to localhost. It runs you through browser login, stores the PAT locally, and starts the daemon.

Next steps