Take an Example to Production
The tutorials teach deployment, persistence, workers, and object storage. Their notes UI has no authentication, and exports and job records have no retention policy. Complete these steps before using an example with real users or sensitive data.
1. Establish application boundaries
Add authentication and authorization to notes, exports, and downloads. Validate inputs and upload sizes, and add appropriate request limits. Keep private bucket credentials on the server. Decide how long to keep notes, export files, and queue status records, then implement deletion for each storage system.
Read Designing Apps for d2o for stateless instances, temporary files, shared sessions, startup validation, logging, connection pools, graceful shutdown, and safe retries.
2. Create separate deployment environments
Keep tutorial data in its disposable Development Environment. Create the real app’s development, staging, and production Environments separately, each with its own databases, buckets, and secrets. Link the build Environment to your GitHub or GitLab repository, enable Wait for CI, and use promotion to move a tested build through staging into protected production.
Review the provider’s Wait for CI behavior, including what happens when a commit has no checks. If you push from a CI job instead, follow Deploying from CI, including deployment verification.
3. Version settings and migrations
Move process selection, health checks, and the release command into d2o-paas.yaml. The tutorials run schema initialization manually so you can inspect the result. For production, use versioned, repeatable migrations as a release command, rather than starting a migration independently in every replica.
The examples’ migrate process illustrates initialization; it is not a complete schema-evolution system. Adopt your framework’s migration tooling before changing an existing schema. Test migrations while the previous version is still serving, and test a code rollback against the updated database. Follow the safe migration sequence.
4. Choose durability and recovery
Review what survives failures and what is backed up. Use attachments instead of copying database or S3 credentials. Redis-only exports and queue status are disposable: if exports must remain discoverable after Redis loss, store their job metadata in the primary database and add recovery/reconciliation logic.
Choose a suitable object-storage tier and keep independent copies where required. Practise the restore procedure before an incident. High availability does not recover accidental deletion, and deleting a database also deletes its platform backups.
5. Validate availability and operations
Add a fast health check and graceful shutdown, then test replacing both web and worker instances. Use at least two web instances for production availability unless the application requires a singleton; size connection pools and memory for the total replica count. Verify worker retries cannot duplicate business effects.
Follow deploys to Live, inspect logs and metrics, and practise rollback in staging. Finish the production checklist.
6. Remove disposable resources
Download anything you want to keep before deleting a tutorial Environment. Use the language tutorial’s Troubleshooting & Cleanup chapter to review and remove its resources. Deleting an Environment permanently removes its apps and data; stopping local Docker Compose services does not delete hosted resources.
Return to the language tutorials to compare another framework.