Deploying

Dashify has three things you can deploy: the backend (API + worker), the frontend (browser app), and this documentation site. Each one has its own command and its own destination.

Deploying the backend (one command)

pnpm deploy:backend

Run from the repo root. The script does five things in order:

1. Stops the running api and worker containers gracefully.
2. Removes the stopped containers so nothing stale lingers.
3. Removes the old Docker image so the next build cannot accidentally use cached layers from a different commit.
4. Rebuilds the image from scratch (--no-cache) using the server/Dockerfile.
5. Starts the new containers detached so the terminal returns control to you.

The whole rebuild takes a couple of minutes. When it finishes, the new code is live on http://localhost:6001.

Deploying the frontend (one command)

pnpm deploy:frontend

Same lifecycle, but scoped to the web service:

1. Stop the running web container.
2. Remove the container.
3. Remove the old client Docker image.
4. Rebuild the client image from client/Dockerfile with --no-cache.
5. Start the new container detached.

When it finishes, the rebuilt browser app is live on http://localhost:3000.

Deploying the documentation site

This documentation lives at dashify-docs.nauman.live. It is hosted on GitHub Pages and rebuilt automatically every time something under /docs-site/ changes on the main branch.

The pipeline:

To deploy by hand (rare):

pnpm docs:build       # produces docs-site/build/
pnpm docs:deploy      # pushes build/ to gh-pages branch

The custom domain is wired through the static/CNAME file in the docs site, which Docusaurus copies into the build output so GitHub Pages keeps the alias on every deploy.

Production deployment (cloud)

For a real cloud deployment of the backend and frontend, the path is:

1. Push your Docker images to a registry (Docker Hub, GitHub Container Registry, AWS ECR).
2. Run them on a hosting platform, anything that runs containers works (Railway, Fly.io, AWS ECS, DigitalOcean App Platform, your own Kubernetes cluster).
3. Provide production-grade MongoDB, Redis, and Qdrant. Managed options are MongoDB Atlas, Upstash Redis, and Qdrant Cloud.
4. Set every environment variable from server/.env.example with production values.
5. Put a CDN in front of the browser app for static asset caching.

Dashify does not lock you into any specific cloud, every service it depends on has multiple managed providers. The Docker setup that runs locally is intentionally close to what you would deploy.

Environment variables in production

Every secret that lives in server/.env for local dev needs a production equivalent. The most security-critical ones are:

• JWT_SECRET, COOKIE_SECRET, CSRF_SECRET, must be long, random, and rotated if ever leaked.
• MONGODB_URI, must point at the production cluster with TLS enabled.
• REDIS_URL, must be over TLS (rediss://) for managed providers.
• SENTRY_DSN, set in production so errors are reported. The platform reads NODE_ENV=production and only initialises Sentry under that gate.

Never commit production secrets to git. Use the secret manager of your hosting platform.

Rollback

The deploy scripts are intentionally simple and do not roll back automatically. If a release breaks, the rollback procedure is:

1. git revert the offending commit (or check out the previous good tag).
2. Run pnpm deploy:backend (or :frontend) again.

Because the deploy scripts always rebuild from a clean image, rollback is just "deploy the previous good version", there is no half-state.

Key takeaways

• pnpm deploy:backend and pnpm deploy:frontend each rebuild and restart a single tier from a clean image.
• The documentation site auto-deploys to dashify-docs.nauman.live via GitHub Pages on every push to main.
• For cloud production, ship the Docker images to a registry, run them on a container host, and use managed databases.
• Rollback is "deploy the previous version", there is no in-between state.