How this works

Each project can be deployed to a dedicated subdomain on fadafad.com, and each project can have one or more staging slots so changes can be reviewed before going live on the production domain.

1. Set the production target

1. Pick a subdomain (lowercase letters, digits, hyphens). It becomes <name>.fadafad.com.
2. Click Check — this verifies the subdomain is formatted correctly, isn't already taken by another project, and that DNS for it resolves to this server. A green result on all four means you can provision.
3. Set the service port the app listens on locally (e.g., 8091).
4. Set the deploy command that builds and launches the app from the project folder (e.g., ./deploy.sh). The script should bind the app to the PORT env var it receives.
5. Click Save, then Provision subdomain. This writes an nginx vhost, runs certbot --nginx for an HTTPS cert, and reloads nginx.
6. Click Deploy now whenever you want to push the latest code.

2. Add a staging slot (optional)

Staging lives in the Staging tab of this project's Brain. Each slot is its own isolated origin at <slot-name>-<production-subdomain>.fadafad.com, on its own port in the 9000–9099 range. Clean cookies, clean session — no leak between staging and prod.

1. Open Brain → Staging.
2. Click ＋ Add slot → enter a name (e.g. staging1, feature-xyz).
3. Optional: a git branch to deploy from, and/or a deploy command that overrides the project default.
4. The server auto-picks a free port, writes the nginx vhost, issues a cert, and records the slot.
5. Click Deploy on a slot to push code to it. Click Promote to prod to run the project's deploy command against the production port.
6. Click Delete to tear down the slot (nginx vhost removed, cert deleted, DB row dropped — the project folder itself is untouched).

3. Deploy-script contract

The deploy command runs from the project folder with these env vars:

• PORT — the port to bind the app to. For slot deploys, this is the slot's auto-assigned port; for promotion, this is the project's production port.
• STAGING_SLOT — the slot name (e.g., "staging1") on staging deploys. Empty for production deploys.
• GIT_BRANCH — set only if a branch was configured on the slot.

A minimal deploy.sh might look like:

#!/usr/bin/env bash
set -euo pipefail
if [ -n "${GIT_BRANCH:-}" ]; then git fetch && git checkout "$GIT_BRANCH" && git pull; fi
# Build if needed:
# npm ci && npm run build
# Run:
#   for staging slots:  PORT=$PORT node server.js &
#   for prod:           systemctl restart myapp.service   # where myapp reads $PORT

4. Availability check — what each line means

• format valid — lowercase letters/digits/hyphens, not starting/ending with hyphen.
• DB available — no other project here has already claimed this subdomain.
• nginx vhost free — no /etc/nginx/sites-available/<fqdn> already exists.
• DNS resolves / points to us — the subdomain's A record actually resolves to this droplet's IP. Required before certbot can issue a cert.

Heads up: every imagine service restart kills any in-flight prompts. You'll see a Failed: interrupted: server restarted banner on anything that was streaming at the moment. Re-run the prompt and it'll pick up cleanly.