Some checks failed
Deploy MineGeo to Dokploy / deploy (push) Failing after 3m39s
57 lines
3.1 KiB
Markdown
57 lines
3.1 KiB
Markdown
# Production launch
|
|
|
|
The website requires a Node.js host and a persistent rendering worker. Deploy
|
|
this checkout with Node.js 22 or later, run `npm ci`, `npm run setup`, and
|
|
`npm run check`, then start it with `npm start` under your host's process manager.
|
|
The supervisor runs the website and worker together and stops the companion if
|
|
either exits. A host that runs only Next.js must run `npm run worker` separately.
|
|
|
|
Configure these before starting:
|
|
|
|
- `MINEGEO_URL`: the public HTTPS origin, without a path, query or credentials.
|
|
Loopback HTTP is supported for local production checks.
|
|
- `NEXT_PUBLIC_SUPABASE_URL`, `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY`, and the
|
|
server-only `SUPABASE_SECRET_KEY`. The supervisor validates missing keys and
|
|
rejects a server secret in the publishable-key field before starting children.
|
|
- Keep `MINEGEO_ALLOW_ANY_ORIGIN=false`. Production ignores the bypass; the
|
|
supervisor also rejects it at startup. Use `MINEGEO_ALLOWED_ORIGINS` for exact
|
|
aliases and configure your reverse proxy to retain the public Host header.
|
|
- Keep the default loopback binding behind a local HTTPS reverse proxy. Set
|
|
`MINEGEO_HOST=0.0.0.0` only when your hosting/container network requires it.
|
|
- Apply the existing `supabase/migrations` in filename order. This audit adds no
|
|
database migration. Keep the media and raw buckets private.
|
|
|
|
Configure Supabase Auth's Site URL and allowed `/auth/callback` redirects for the
|
|
public origin, email confirmation, working production SMTP, and a minimum
|
|
password length of 12. Enable leaked-password protection when the plan supports
|
|
it; the October 5 audit found it disabled. See the [account guide](account-settings.md)
|
|
and [Supabase password security](https://supabase.com/docs/guides/auth/password-security).
|
|
|
|
The site sends no-store headers for all application API responses, including
|
|
drafts, pairing credentials, tokens and errors. Guest cookies are HttpOnly,
|
|
SameSite=Lax, and Secure for the configured HTTPS public host behind a proxy.
|
|
The response headers prevent framing and MIME sniffing, limit referrers, and
|
|
disable unused camera, microphone and location permissions. Configure HTTPS
|
|
certificates and HSTS at the public reverse proxy.
|
|
|
|
Monitor `/api/v1/health`: HTTP 200 means its database query succeeded; 503 means
|
|
configuration or the data service is unavailable. Also retain worker logs and
|
|
monitor failed/queued jobs; website health does not assert worker liveness.
|
|
Keep Supabase backups enabled and test restoration before storing irreplaceable
|
|
community uploads.
|
|
|
|
After deployment, run:
|
|
|
|
```sh
|
|
npm run test:production -- https://your-public-origin.example
|
|
```
|
|
|
|
Run this from the configured checkout for the same Supabase project. The test
|
|
checks pages/downloads, security headers, invalid map IDs, guest access denial,
|
|
CSRF denial, malformed JSON, session isolation, real signed WebP downloads, and
|
|
all five rounds with idempotent activation/submission and out-of-bounds rejection.
|
|
It removes only its generated guest session. A published map is required.
|
|
|
|
See [the audit record](production-audit.md) for evidence and remaining limits.
|
|
For self-hosted Docker deployment, see [Dokploy deployment](dokploy-deployment.md).
|