From deployment artifact to 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. The production outcome stays with the operator.
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 for review and hardening. It is not a safe deployment configuration to copy unchanged.
Service recovery covers the database and supporting state
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.
Compliance requires review of the region and complete data flow
Choosing infrastructure and a region can support a residency objective. The review must cover the full data flow, processors and subprocessors, logs, telemetry, backups, administrative support, transfers, retention, deletion, encryption, and organizational controls. This guide organizes information and evidence. Legal advice comes from qualified counsel, and project approval from the project's decision owners.
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. Treat them as time-sensitive reference data; this page makes no provider recommendation.
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 | The organization designs and tests the topology, app and worker lifecycle, managed stores, networking, scaling, telemetry, recovery and exit. Open Mercato does not ship this architecture as a 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. The infrastructure location alone provides no evidence of these control outcomes. |
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 lacks named 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 leaves those gaps open.