Development & operations
Run and verify the application without confusing a build, a deployment, or a backup with production readiness.
In this chapter
Runtime boundaries#
The application runs in a container behind HTTPS routing. PostgreSQL is on a private network with separate production and test databases and restricted application roles. The waitlist uses a separate Redis service. Model compute is intended to run separately from the application/database host.
The runtime is configured with a non-root application user, restricted writable paths, and resource bounds. These are useful controls, not a substitute for host maintenance, access controls, dependency review, monitoring, and incident response.
Configuration categories#
| Setting | Purpose | Handling |
|---|---|---|
| APP_ORIGIN | Canonical HTTPS origin for sign-in and mutation checks. | Public value; must match the deployed site exactly. |
| DATABASE_URL | Marketplace database connection. | Server secret; keep off public networks and client bundles. |
| KV / Redis REST settings | Durable waitlist connectivity. | Server secrets; production must fail closed if unavailable. |
| ROBINHOOD_RPC_URL | Wallet verification and future chain access. | Use suitable infrastructure; protect embedded provider credentials. |
| INFERENCE_BASE_URL / API_KEY / MODEL | Operator-side provider configuration. | Authorized endpoint and scoped secret; not public signup input. |
| INFERENCE_ENABLED | Explicit operator adapter activation. | Not permission to bypass customer accounting or launch gates. |
| Operator access secrets | Separate administrative test access. | Keep distinct from user-wallet authentication and rotate securely. |
Local development for authorized maintainers#
npm ci
npm run dev -- --port 3001Do not point disposable registration or financial tests at production storage. A browser UI can render without a configured live provider, but that is not proof that the backend is functional.
Do not share the same .next output between a running development server and a production build/start. This caused missing JavaScript assets during development. Use isolated release builds or coordinate stopping the development process first.
Verification layers#
npx tsc --noEmit --incremental false
node --experimental-strip-types --test lib/beta-access.test.mjs lib/server/inference.test.mjs lib/server/waitlist.test.mjs- Build the release in an isolated environment and inspect dependency audit results without bypassing security controls.
- Run signed-wallet integration tests against an isolated database, including replay and ownership checks.
- Verify browser navigation, drafts, unsupported states, mobile layout, and console errors.
- Test persistence through restarts and recovery from a database disconnect.
- Verify public waitlist access and protected account routes after deployment without inserting test rows into the live waitlist.
- Before enabling inference or funds, add live-provider, metering, concurrency, payment, and reconciliation tests.
Backups and certificates#
Trusted HTTPS and automated certificate renewal have been configured and exercised. Local database backups are scheduled, and an isolated backup restoration has been tested. A backup kept on the same VPS does not protect against losing that VPS.
Off-host backup storage, restoration drills, alerting, retention decisions, and incident ownership remain necessary before production financial use. Restoring an old database also requires a plan for reconciling any chain activity that happened after the backup.
Safe releases and rollback#
- Record the intended release and verify its implementation status.
- Build and test before replacing the running application.
- Confirm configuration, database privileges, origin, and network restrictions.
- Keep a recoverable prior artifact and verify the new release after activation.
- Treat schema changes and chain/accounting state differently from a frontend rollback.
- Do not report a local build or a candidate container as a deployed feature.