A deployment artifact is not managed operations
The scaffolder creates a standalone application base. The VPS guide describes an application, PostgreSQL, Redis, and Meilisearch stack. The Railway command can prepare a project, environment, database, Redis, application, worker, variables, domain, and health check. Each artifact reduces setup work, but none accepts responsibility for the production outcome.
Production needs more than a production-style file
The reviewed Compose file includes the application, PostgreSQL, Redis, Meilisearch, an attachment volume, and named data volumes. It also sets NODE_ENV and MEILI_ENV to development and contains local, demo, and development defaults. It is a reference to review and harden, not a safe recipe to copy unchanged.
A database dump does not restore the whole service
Recovery planning must separate PostgreSQL, Redis state, search indexes, attachments or object storage, deployment configuration and state, secrets, and evidence from restoration exercises. An index may be rebuildable and a cache disposable only after dependencies and procedures are verified. A pg_dump file alone does not prove recovery readiness.
On Railway, durability for locally stored attachments is opt-in. Without a volume or durable external object storage, files written to the service filesystem can be lost during redeploy or service replacement.
A chosen region does not guarantee compliance
Choosing infrastructure and a region can support a residency objective. The review must still cover the full data flow, processors and subprocessors, logs, telemetry, backups, administrative support, transfers, retention, deletion, encryption, and organizational controls. This is a responsibility guide, not legal advice.
Public-source and review limitations
The review was performed on 14 July 2026 at revision 01911d00e28f44cf484d0b1d04860dcfef5370bf. At that time, the public VPS URL rendered the documentation home, so exact facts are pinned to repository source. External-provider prices, limits, regions, and behavior can change and are not recommendations here.
What the reviewed repository actually ships
| Artifact | Supplies | Does not prove | Pinned source |
|---|---|---|---|
| Standalone application scaffolder2026-07-14 · high | A generated application base plus documented development and production-style Docker starting points. | A hosted service, hardened configuration, monitoring, recovery or support. | 01911d00e28f |
| VPS guide and production-style Compose template2026-07-14 · high | Application, PostgreSQL, Redis, Meilisearch and durable-volume examples. | Production hardening: the reviewed template still contains development, demo and local-secret defaults. | 01911d00e28f |
| Railway deployment command and guide2026-07-14 · high | Provisioning for an environment, PostgreSQL, Redis, app, optional worker, variables, domain and health check. | Attachment durability without an opted-in volume or external durable storage, nor a complete operating model. | 01911d00e28f |
Four hosting patterns without a universal winner
| Pattern | Classification | Ownership boundary |
|---|---|---|
| Controlled VPS / reference Compose | shipped reference | The organization or operator owns the host, TLS, network, secrets, patches, observability, backups, restoration and incidents. |
| Railway deployment path | shipped path | Railway supplies selected platform resources; the application owner still assigns data, attachment, security, recovery, supplier and incident responsibilities. |
| Organization-designed cloud or container architecture | implementation architecture | Design and test the topology, app and worker lifecycle, managed stores, networking, scaling, telemetry, recovery and exit; this is not a shipped turnkey target. |
| On-premises or private infrastructure | implementation architecture | The organization designs and tests hardware or virtualization, networks, stores, backups, recovery, monitoring, maintenance and support; private location alone proves no control outcome. |
Persistence and recovery are separate decisions
| Asset or evidence | Required decision | Insufficient on its own |
|---|---|---|
| PostgreSQL | Define backup scope, retention, encryption and a tested restore with application-level reconciliation. | A dump file or successful backup job alone. |
| Redis state | Classify cache, queue and durable state; prove whether each use can be discarded or reconstructed. | Assuming all Redis data is disposable. |
| Search indexes | Document the source of truth, reindex procedure, time and degraded behavior. | A named volume without a rebuild test. |
| Attachments / object storage | Choose durable storage, backup/versioning, access controls, deletion and restore verification. | A database backup or an ephemeral service filesystem. |
| Configuration and deployment state | Version deployment definitions and retain the settings needed to recreate each environment. | Source code without environment-specific state. |
| Secrets and keys | Assign protected custody, rotation, recovery and break-glass access without exporting values into this worksheet. | Sample defaults or a plaintext environment file. |
| Recovery evidence | Run a full exercise, reconcile business behavior, record time and gaps, then retest remediation. | Independent component backups without a service restoration. |
Local planning tool
Hosting responsibility worksheet
Assign roles, supplier boundaries, evidence, review dates, and a project-specific stop condition. A row cannot be marked verified until every required field is present.
Privacy: Local only: entries stay in this browser storage and exports. Do not enter credentials, personal data, or secret values.
Verified rows: 0/21
| Decision or control | Accountable owner | Operating owner | Supplier, if any | Required evidence | Status | Review date | Stop condition |
|---|---|---|---|---|---|---|---|
| Hosting model and supplier boundary | |||||||
| Application build and release | |||||||
| Worker topology and lifecycle | |||||||
| PostgreSQL operation and recovery | |||||||
| Redis uses and durability | |||||||
| Search operation and rebuild | |||||||
| Attachment and object-storage durability | |||||||
| Configuration and deployment state | |||||||
| Secrets, keys and rotation | |||||||
| TLS, DNS and network controls | |||||||
| Administrative identity and access | |||||||
| Monitoring, logging and alert response | |||||||
| Capacity, scaling and performance | |||||||
| Operating-system, platform and dependency patching | |||||||
| Backup schedule, retention and protection | |||||||
| Full-service recovery exercise | |||||||
| Data location and complete data flow | |||||||
| Processors, subprocessors and contracts | |||||||
| Incident response and communications | |||||||
| User support and operational handover | |||||||
| Supplier exit and service portability |
When this hosting approach is a poor fit
Pause when the organization cannot name long-term application and operations owners, cannot accept responsibility left outside a supplier contract, or needs a managed product with a certified operating outcome. A private region, copied Compose file, green health check, or database dump cannot close those gaps.
Method, assumptions and limitations
Reviewed 14 July 2026. Product facts were checked against both the public code at the cited repository revision and official documentation. Where documentation and code differ, this guide describes behavior supported by code. Interpretations and recommendations concern implementation work, not product guarantees.
This material is not a quote, audit, certification, or legal, tax, or accounting advice. Edition, enabled modules, configuration, custom code, infrastructure, data, third-party providers, and operating practices affect the outcome.
Primary source collections: code repository, documentation, public releases.