Guides

Deploying a monorepo with a frontend, an API and a worker

How the agent handles a repository that contains a Next.js frontend, a FastAPI service and a Celery worker — and what you can do to make its plan even better.

Walkthrough8 min readUpdated September 2026

Start with the plan

Connect the repository and run shipsanely plan. For a typical monorepo the agent reports three services, two datastores and a list of environment variables. Read this before deploying: it is the agent's understanding of your application, and the cheapest place to correct it.

Services it finds

The Next.js app is recognised from package.json and next.config.js; FastAPI from the uvicorn entry point; the Celery worker from its broker configuration. Each becomes its own service with its own servers.

Datastores it infers

SQLAlchemy models plus an Alembic folder mean PostgreSQL with migrations. The Celery broker URL means Redis with persistence enabled. Both are provisioned privately and their URLs injected.

Secrets

Anything the agent cannot infer — a Stripe key, an OAuth secret — shows in the plan as "needs value". Set them once with shipsanely env set; they are encrypted and injected only into the services that reference them.

First deploy

shipsanely deploy builds three release artifacts, provisions infrastructure, runs Alembic migrations against a fresh snapshot, starts all services and probes /, /api/health and a detected route. Only then is the release promoted.

Improving the plan

If your worker has an unusual entry point or the frontend needs a build-time variable, add a short SHIPSANELY.md: plain sentences like "the worker starts with python -m app.worker". The agent reads it on every analysis.

Early access. Behaviour described here reflects the current agent and may improve between releases. See the changelog.

Ready to connect a repository?

Early access is open for a limited number of teams. Tell us about your stack and we will reply with next steps.

Request early access