<p>A useful bug report describes what someone did, what they expected, and what happened. I remove customer details and rewrite the report as observable behavior before Codex searches the code. That statement becomes the test name and keeps the fix tied to the defect.</p><p>I use synthetic fixtures and the smallest reproducible input. The goal is a test that fails for the original reason, not a snapshot of the current implementation.</p>

<h2>Rewrite the report</h2>

<p>I capture the route or function, initial state, action, expected result, observed result, and environment. Screenshots may show the symptom but usually need a text description. I remove names, account IDs, messages, and private URLs.</p><p>Ambiguous reports become questions. I do not let the assistant invent missing acceptance criteria.</p>

<h2>Trace the narrowest path</h2>

<p>Codex searches for the user-facing entry point, handler, data transformation, and existing tests. I read the nearby code and identify the smallest unit or integration boundary that can reproduce the problem.</p><p>A browser test may be necessary for focus, layout, or navigation bugs. A pure transformation should not require an end-to-end suite.</p>

<h2>Make the test fail first</h2>

<p>I add a fixture that represents the defect and run the focused test against unchanged code. The failure message must point to the expected behavior. A test that passes before the fix or fails in setup does not prove the bug.</p><p>I keep the pre-fix output in the work note. That evidence guards against changing the assertion to match the implementation.</p>

<h2>Apply the narrow fix</h2>

<p>I change the smallest responsible branch, validation rule, query, or component. I review related callers and boundary cases. Codex may suggest a broader abstraction; I defer it unless the bug exposes repeated logic that the tests can cover.</p><p>Security and authorization fixes include a denial test. Data fixes include malformed and missing inputs.</p>

<h2>Run focused and full validation</h2>

<p>The new regression test passes after the patch. Then I run nearby tests, typecheck, lint, the full suite, and the production build required by the repository. I exercise the original user path where practical.</p><p>I record the command results and commit. A generated test without a recorded failing state is weaker evidence.</p>

<h2>Keep the test maintainable</h2>

<p>The test names behavior, uses a small fixture, and avoids internal details that can change safely. I add a comment only when the regression history explains a non-obvious boundary.</p><ul><li>The report is anonymized.</li><li>Acceptance behavior is explicit.</li><li>The test fails before the fix.</li><li>The patch remains narrow.</li><li>Full validation passes afterward.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev helps teams improve application reliability through <a href="/services/devops-consulting">DevOps and testing support</a>. Use the <a href="/contact">contact page</a> to describe the observable bug without customer data.</p>

See how I use Codex for regression testing by rewriting bug reports as behavior, reproducing failures, adding tests, and validating the narrow fix.

How I Turn Bug Reports into Regression Tests with Codex

Translate an anonymized bug report into observable behavior, a failing test, a narrow fix, and full validation with Codex.

<p>During a production incident I stabilize the service before asking Codex to investigate. Rate limits, rollback, feature flags, or traffic controls may reduce harm while the cause remains unknown. The incident lead decides those actions and records them on the timeline.</p><p>Codex receives sanitized evidence: UTC timestamps, generalized request paths, status codes, durations, deployment hashes, and synthetic identifiers. Customer records and credentials stay in authorized systems.</p>

<h2>Stabilize and assign roles</h2>

<p>The incident lead owns decisions, an operator performs approved changes, and a recorder maintains the timeline. I define the affected user journey and current impact without copying customer messages into the AI thread.</p><p>Read-only diagnosis can begin while a rollback or containment action runs. Competing changes stop unless the lead approves them.</p>

<h2>Build a sanitized timeline</h2>

<p>I record deployments, alerts, error-rate changes, dependency events, and operator actions in UTC. Identifiers become stable synthetic labels. I keep raw evidence in the approved incident system and share only the fields needed to test a hypothesis.</p><p>Codex can compare the timeline with repository history and deployment configuration. It should distinguish observed correlation from cause.</p>

<h2>Test causes with read-only checks</h2>

<p>I start with deployed commit, service health, configuration names, queue depth, recent errors, and dependency status. Each hypothesis predicts an observation. A failing prediction removes the hypothesis instead of producing another speculative change.</p><p>Queries use bounded time windows and selected fields. I avoid dumping complete logs or database rows.</p>

<h2>Review every proposed action</h2>

<p>A proposed command states target, expected effect, risk, rollback, and approver. I resolve account, region, cluster, and service before execution. Destructive changes wait even when the model labels them urgent.</p><p>If Codex suggests widening permissions or disabling a control, I look for a safer diagnostic path and require stronger evidence.</p>

<h2>Verify recovery</h2>

<p>I compare error rate, latency, queue behavior, and the affected user path with the pre-incident baseline. A quiet log can mean traffic disappeared, so I include successful requests and monitoring coverage.</p><p>The fix receives a regression test or configuration check. Temporary mitigations get an owner and removal date.</p>

<h2>Close the privacy loop</h2>

<p>I review the thread, attachments, copied commands, and generated files for sensitive data. Any exposed credential rotates. The incident report uses bounded facts and separates verified cause from open questions.</p><ul><li>Service stabilization comes first.</li><li>Shared evidence is sanitized.</li><li>Diagnosis begins read-only.</li><li>Writes require explicit approval.</li><li>Recovery and privacy receive verification.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev helps teams prepare safer incident and deployment procedures through <a href="/services/devops-consulting">DevOps consulting</a>. Use the <a href="/contact">contact page</a> for a process review, without customer data or private logs.</p>

Use Codex during production incident response without exposing customer data by sanitizing logs, limiting access, testing causes, and recording evidence.

Using Codex During a Production Incident Safely

Stabilize production, build a sanitized timeline, test causes with read-only checks, and document the verified fix without customer records.

Using Codex During a Production Incident Without Exposing Customer Data

<p>I use Codex to inspect deployment configuration, run repeatable checks, and compare the deployed result with the release request. I do not hand it unrestricted production credentials or an open-ended instruction to fix deployment. The task names the environment, allowed change, and commands that may run.</p><p>The <a href="https://developers.openai.com/codex/use-cases">official Codex use-case documentation</a> shows workflows for codebase analysis, review, testing, and automation. A deployment still needs an authorized person to approve external changes and confirm business timing.</p>

<h2>Define authority and target</h2>

<p>The task identifies the repository, branch, cloud account, region, application, and environment. It also lists forbidden actions such as deleting resources, rotating secrets, or changing DNS. I resolve these values with read-only checks before any deployment command.</p><p>Environment variables never substitute for a verified target when a command can alter production. I print safe identifiers and compare them with the release record.</p>

<h2>Inspect deployment configuration</h2>

<p>I ask Codex to trace the package script, CI workflow, build specification, infrastructure definitions, and health checks. The review looks for branch mismatches, missing variables, broad roles, and commands that depend on local state.</p><p>I verify each concern in the current files. Generated suggestions do not override repository instructions or cloud documentation.</p>

<h2>Run preflight checks</h2>

<p>The preflight uses the project's supported typecheck, lint, tests, and production build. Infrastructure changes get a diff or plan. Database changes get compatibility and backup checks. I attach results to the exact commit.</p><p>A green preflight is permission to request deployment, not proof that the deployment will succeed.</p>

<h2>Keep secrets out of the conversation</h2>

<p>Codex can work with secret names and redacted configuration. Values stay in the platform secret manager. I remove tokens from copied logs, avoid commands that print environments, and review tool output before sharing it.</p><p>If a credential appears in a prompt, log, or repository, I treat it as exposed and rotate it through the owning system.</p>

<h2>Verify after deployment</h2>

<p>I check the deployed commit, job result, critical routes, authentication, one safe transaction, logs, and monitoring. The checks match the user journey changed by the release. I compare staging and production endpoints to catch environment mix-ups.</p><p>Rollback criteria are written before release. If they trigger, the operator follows the runbook rather than asking the model to improvise under pressure.</p>

<h2>Record human decisions</h2>

<p>The release note separates commands Codex ran, evidence it gathered, and decisions a person made. Rejected suggestions remain visible when they explain a tradeoff.</p><ul><li>Target and authority are explicit.</li><li>Preflight evidence names the commit.</li><li>Secrets remain in secret storage.</li><li>Production changes require approval.</li><li>Health checks verify the live system.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev designs controlled release processes through <a href="/services/devops-consulting">DevOps consulting</a>. Request a deployment workflow review through the <a href="/contact">contact page</a> without including credentials or private account identifiers.</p>

Use Codex safely in a DevOps workflow by scoping the environment, inspecting configuration, running preflight checks, and verifying the released commit.

Using Codex Safely in a DevOps Deployment Workflow

Use Codex for deployment preparation and verification while keeping credentials, approvals, and release decisions under human control.

<p>I use ChatGPT to organize sanitized notes and Codex to compare a runbook with the repository commands it describes. The first draft is documentation, not an approved procedure. I test every command in a safe environment and record the expected output before another developer relies on it.</p><p>A useful runbook helps an operator decide whether to continue, stop, or escalate. A list of commands without targets and failure conditions can make an incident worse.</p>

<h2>Name the goal and owner</h2>

<p>The title describes the outcome, such as restoring a failed deployment or rotating an API credential. The first section names the service owner, approver, communication channel, and situations where the runbook applies.</p><p>I include explicit non-goals. An application restart procedure should not imply permission to change database schema or DNS.</p>

<h2>List prerequisites</h2>

<p>I record required access, tool versions, working directory, environment, backup state, and safe identifiers. Secret values remain in the owning secret manager. The operator verifies account and region with read-only commands.</p><p>Missing prerequisites stop the procedure. The runbook does not tell someone to work around access controls during an incident.</p>

<h2>Use copy-safe commands</h2>

<p>Commands use explicit targets and descriptive placeholders. I avoid unresolved destructive variables and broad recursive paths. Each command states whether it reads or changes state.</p><p>ChatGPT may improve wording, while Codex checks package scripts and file paths. I compare every suggestion with current code and official tool documentation.</p>

<h2>Show expected output and branches</h2>

<p>After each important command I include a short expected result and the next action for success or failure. Exact volatile output is less useful than a stable signal such as status, count range, or commit hash.</p><p>I define escalation points. Repeating a failed write command without understanding the error is not recovery.</p>

<h2>Document rollback</h2>

<p>The rollback section identifies the prior artifact, data restore point, configuration snapshot, and approval needed. Some changes cannot be reversed by redeploying code, so the runbook separates application, infrastructure, and data steps.</p><p>I test rollback in a non-production environment and record limitations rather than promising full recovery.</p>

<h2>Exercise and maintain the runbook</h2>

<p>Another developer follows the draft without oral help. I note unclear steps, missing access, unsafe assumptions, and elapsed time. The owner updates the runbook after platform or repository changes.</p><ul><li>Goal and scope are explicit.</li><li>Targets are verified read-only.</li><li>Commands avoid secret output.</li><li>Expected results guide decisions.</li><li>Rollback has test evidence.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev helps teams turn deployment knowledge into tested operating procedures through <a href="/services/devops-consulting">DevOps consulting</a>. Request a runbook review through the <a href="/contact">contact page</a> using sanitized examples.</p>

Write an AI-assisted DevOps runbook with a clear goal, owner, prerequisites, copy-safe commands, expected output, rollback steps, and test evidence.

Writing DevOps Runbooks with ChatGPT and Codex

Turn commands and incident notes into a tested DevOps runbook with owners, prerequisites, expected output, rollback, and safe targets.

<p>I ask Codex to review a change after the requested behavior works, not as a substitute for understanding the change. I provide the requirement, repository rules, and validation commands. Then I inspect the diff and verify each finding against the code before accepting a patch.</p><p>OpenAI's <a href="https://developers.openai.com/codex/use-cases">official Codex use-case documentation</a> includes understanding codebases, fixing bugs, testing, and reviewing changes. Those capabilities help with evidence gathering. I remain responsible for scope, credentials, production access, and the decision to ship.</p>

<h2>Start with the requested behavior</h2>

<p>I restate the change as observable behavior and list what must remain unchanged. That gives the review a boundary. A request such as "fix publishing" is too broad; "a successful publish leaves the review queue and a failed mutation remains visible" can be tested.</p><p>I include repository instructions and the commands maintainers trust. The agent should not invent a new quality gate when the project already has one.</p>

<h2>Read the diff before asking for fixes</h2>

<p>I review changed files, generated files, and unexpected edits. Then I ask Codex to trace callers, shared types, tests, and user-facing paths affected by the diff. This often finds a consumer that a focused implementation missed.</p><p>I separate observations from proposed changes. A large refactor attached to a small bug needs stronger evidence than a narrow correction.</p>

<h2>Verify every finding</h2>

<p>An AI review can misread intent, review stale code, or flag a safe pattern. I reproduce each reported defect with a test, type error, failing request, or direct code path. Findings without evidence remain review notes.</p><p>I reject suggestions that expand authorization, weaken validation, or change public behavior without a requirement. Agreement from two model passes is not independent proof.</p>

<h2>Run focused checks first</h2>

<p>I run the closest test and type check while the cause is fresh. Once those pass, I run the full lint, test, and production build expected by the repository. I record the command, exit status, and commit.</p><p>A passing test suite can still miss visual or environment-specific behavior. I exercise the changed user path in the target environment when the change touches deployment, authentication, or content.</p>

<h2>Review privacy and operational scope</h2>

<p>I remove tokens, account IDs, customer text, and private URLs from prompts and screenshots. Tool access stays within the repository and systems authorized for the task. Destructive commands and external writes receive a separate review.</p><p>I inspect generated commands before execution. A correct command aimed at the wrong environment is still a production incident.</p>

<h2>Keep a review record</h2>

<p>The final note names the requirement, changed files, verified findings, rejected suggestions, test results, and remaining risk. That record gives a maintainer something concrete to review.</p><ul><li>Requirement and non-goals are written.</li><li>The diff and nearby consumers were inspected.</li><li>Findings have evidence.</li><li>Repository checks passed.</li><li>A human approved the release.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev offers <a href="/services/devops-consulting">DevOps consulting</a> and application review for teams adopting AI-assisted development. Use the <a href="/contact">contact page</a> to describe the workflow without including proprietary code or credentials.</p>

See my Codex code review workflow for inspecting a diff, tracing nearby consumers, verifying findings, running tests, and checking deployed behavior.

How I Use Codex to Review a Change Before I Ship It

Use Codex to inspect a diff, trace affected consumers, verify findings, and run release checks while keeping human approval in control.

<p>A failed CI log can contain hundreds of follow-on errors. I begin with the failing command and the first error that explains why the command stopped. ChatGPT can help summarize a pasted, sanitized excerpt. Codex can inspect the repository and run the matching command when it has authorized access.</p><p>I do not paste a complete log until I remove secrets, private package URLs, account identifiers, and customer data. The smallest useful excerpt often contains the command, runtime version, stack trace, and nearby setup lines.</p>

<h2>Capture the exact failure</h2>

<p>I record the workflow name, job, commit, command, exit code, and first useful error. Later errors may be symptoms of a missing generated file or failed install. I keep enough lines above the error to see environment setup.</p><p>I ask the assistant to distinguish facts in the log from hypotheses. A confident cause without a matching line or repository path stays unverified.</p>

<h2>Compare local and CI assumptions</h2>

<p>I compare Node and package-manager versions, lockfile use, environment variables, operating system, working directory, caches, and generated artifacts. The local command may pass because an ignored file exists or a developer shell exports a value.</p><p>I reproduce with the CI command in a clean environment where practical. Changing several dependencies before reproducing destroys evidence.</p>

<h2>Inspect the smallest relevant files</h2>

<p>Codex can trace the failing script into its configuration and imports. I limit the initial read to the workflow file, package script, failing module, and nearby test. This reduces speculation across unrelated code.</p><p>If the error concerns a missing secret, I verify the key name and job scope without revealing the value. If it concerns permissions, I inspect the required action before expanding a role.</p>

<h2>Make one testable change</h2>

<p>I choose the narrowest change that explains the failure: pin the supported runtime, generate the expected artifact, correct the path, or fix the type error. I add a regression test when the failure came from application behavior.</p><p>I avoid "cleanup" in the same patch. A small diff makes it clear whether the original cause was correct.</p>

<h2>Rerun the same command</h2>

<p>The original failing command must pass with the same relevant environment. I then run the surrounding project checks because a narrow fix can break another package or platform. CI receives the committed change and produces the final evidence.</p><p>I do not declare success from a local substitute if the failure happened only in the hosted runner.</p>

<h2>Write the incident note</h2>

<p>I record the first error, cause, fix, validation, and prevention. Repeated environment drift may justify a pinned toolchain or preflight script.</p><ul><li>Logs are sanitized.</li><li>The first causal error is identified.</li><li>Local and CI versions are compared.</li><li>One narrow fix is tested.</li><li>The hosted job passes on the target commit.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev helps teams diagnose builds and deployment pipelines through <a href="/services/devops-consulting">DevOps consulting</a>. Send the sanitized command and first error through the <a href="/contact">contact page</a>, not the full private log.</p>

Use AI-assisted CI debugging to isolate the first useful error, compare local and CI assumptions, inspect relevant files, and prove the fix safely.

Debugging a Failed CI Build with ChatGPT and Codex

Find the first useful CI error, compare environments, test the smallest cause, and prove the fix with the original command.

<p>I decide what an AI assistant needs before I provide code, logs, screenshots, or tool access. Most debugging work needs structure and error context, not a customer's message, full token, private hostname, or complete production record.</p><p>Redaction is part of preparing the task. I replace identifying values with consistent synthetic ones so relationships remain visible without exposing the original data.</p>

<h2>Classify the material</h2>

<p>I mark credentials, personal data, client-confidential data, internal infrastructure, proprietary code, and public information. The classification determines whether the material can be used, must be reduced, or should stay out of the workflow.</p><p>A value can be harmless alone and identifying in combination. A timestamp, rare route, and exact error may reveal a customer incident even after the name is removed.</p>

<h2>Redact while preserving structure</h2>

<p>I replace tokens with <code>TOKEN_REDACTED</code>, accounts with stable fictional IDs, domains with <code>example.invalid</code>, and user records with synthetic fixtures. Consistent replacements let the assistant trace one identity across a sanitized log.</p><p>I remove authorization headers and query strings before copying a request. Screenshots receive the same review as text.</p>

<h2>Use the smallest code scope</h2>

<p>I share the failing function, type, test, and necessary configuration instead of an entire proprietary repository when broad access is not required. If Codex has repository access, the task and filesystem scope still state what it may inspect and change.</p><p>External systems remain read-only during diagnosis unless the user authorizes a bounded write.</p>

<h2>Review generated commands</h2>

<p>I resolve targets before executing commands that deploy, delete, rotate, migrate, or send messages. I reject unresolved variables, broad globs, and output that may print environment values. Commands run in a non-production environment first when possible.</p><p>A model can produce syntactically correct destructive commands. Human review supplies authority and context.</p>

<h2>Respond to accidental exposure</h2>

<p>If a secret enters a prompt, log, commit, or screenshot, I revoke or rotate it. Deleting the visible copy does not prove downstream copies disappeared. I review access logs and affected systems according to the incident plan.</p><p>Client data exposure follows the organization's privacy and notification procedure. The developer should not improvise legal conclusions.</p>

<h2>Use a pre-share checklist</h2>

<p>I pause before every upload or pasted block and search for common credential formats, email addresses, hostnames, account numbers, and message content. Automated secret scanning helps but does not replace context review.</p><ul><li>Only necessary files are in scope.</li><li>Examples use synthetic values.</li><li>Tool permissions match the task.</li><li>Commands have explicit targets.</li><li>Exposed credentials are rotated.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev can help teams define safer automation and development practices through <a href="/services/devops-consulting">DevOps consulting</a>. Discuss the policy through the <a href="/contact">contact page</a> without pasting private logs or credentials.</p>

Improve AI coding assistant security with rules for redacting secrets and client data, using synthetic examples, limiting access, and reviewing commands.

Keeping Secrets and Client Data Out of AI Coding Workflows

Redact credentials and customer data, use synthetic examples, restrict tool scope, and review commands before AI-assisted work changes systems.

<p>This guide shows a manual Strapi deployment on Railway with PostgreSQL and persistent uploads. It avoids a one-click template so you can see which service owns the application, database, secrets, and media.</p>
<p>Railway's current <a href="https://docs.railway.com/guides/strapi" target="_blank" rel="noopener noreferrer">Strapi deployment guide</a> recommends PostgreSQL for the application and either a Railway Volume or an S3-compatible bucket for uploads. The default service filesystem is ephemeral, so an upload stored only inside the application container can disappear during a deployment.</p>

<h2>What this deployment includes</h2>
<ul>
  <li>A Strapi application deployed from a GitHub repository</li>
  <li>A separate Railway PostgreSQL service</li>
  <li>Production secrets stored in Railway variables</li>
  <li>Persistent media through a volume or object storage</li>
  <li>A public domain, logs, and a documented backup owner</li>
</ul>

<h2>1. Create the Strapi project locally</h2>
<pre><code>npx create-strapi@latest my-strapi-app</code></pre>
<p>Select PostgreSQL when the installer asks for a database. Run the project locally, create the initial administrator, and test the content types and permissions before connecting a production database.</p>
<p>Commit the application code to GitHub. Keep <code>.env</code>, database dumps, API tokens, and generated secrets out of the repository.</p>

<h2>2. Create the Railway services</h2>
<ol>
  <li>Create a Railway project.</li>
  <li>Add a PostgreSQL database service.</li>
  <li>Add the Strapi application from its GitHub repository.</li>
  <li>Confirm the application service's detected build and start commands in the deployment settings.</li>
</ol>
<p>Railway exposes database variables from the PostgreSQL service. Reference those variables from the Strapi service instead of copying a password into source control.</p>

<h2>3. Configure production variables</h2>
<p>The exact configuration can change with the Strapi version and project setup. Railway's guide currently uses variables shaped like these:</p>
<pre><code>DATABASE_CLIENT=postgres
DATABASE_HOST=${{Postgres.PGHOST}}
DATABASE_PORT=${{Postgres.PGPORT}}
DATABASE_NAME=${{Postgres.PGDATABASE}}
DATABASE_USERNAME=${{Postgres.PGUSER}}
DATABASE_PASSWORD=${{Postgres.PGPASSWORD}}
DATABASE_SSL=true
NODE_ENV=production

APP_KEYS=&lt;four comma-separated random values&gt;
API_TOKEN_SALT=&lt;random value&gt;
ADMIN_JWT_SECRET=&lt;random value&gt;
JWT_SECRET=&lt;random value&gt;</code></pre>
<p>Generate each secret independently. Do not reuse local development values in production. If your project needs additional transfer, encryption, email, upload-provider, or frontend URL variables, document the owner and rotation process for each one.</p>

<h2>4. Make uploaded media persistent</h2>
<p>Strapi writes local uploads to <code>public/uploads</code> by default. Railway documents two persistence options:</p>
<ul>
  <li>Attach a Railway Volume at <code>/app/public/uploads</code>. This is straightforward, but the volume is tied to one service instance.</li>
  <li>Configure Strapi's S3 upload provider with a Railway Storage Bucket or another supported object store. This is a better fit when media must be separate from the application container.</li>
</ul>
<p>Choose the option before editors upload production assets. Moving media later requires an inventory, transfer plan, URL review, and recovery test.</p>

<h2>5. Deploy and verify</h2>
<ol>
  <li>Trigger a deployment and read the build logs.</li>
  <li>Generate a public domain under the application's networking settings.</li>
  <li>Open <code>/admin</code> and confirm that the administrator can sign in.</li>
  <li>Create and retrieve a test record through the API.</li>
  <li>Upload a test image, redeploy, and confirm that the image still exists.</li>
  <li>Review public roles and API permissions before connecting the frontend.</li>
</ol>

<h2>6. Plan backups and updates</h2>
<p>A running deployment is not a recovery plan. Assign responsibility for PostgreSQL backups, uploaded media, secret rotation, dependency updates, Strapi upgrades, log review, and restore testing. Record the steps needed to rebuild the application if the service or account becomes unavailable.</p>

<h2>Common deployment failures</h2>
<ul>
  <li><strong>The build succeeds but the app cannot start:</strong> check the start command, production Node version, database variables, and secret values.</li>
  <li><strong>The admin loads but content requests fail:</strong> review the content type, public or authenticated role permissions, CORS settings, and frontend API URL.</li>
  <li><strong>Uploads disappear after a redeploy:</strong> the application is still writing to the ephemeral filesystem. Attach a volume or configure object storage.</li>
  <li><strong>The database connection fails:</strong> confirm the service references the Railway PostgreSQL variables and uses the correct SSL setting for the deployed environment.</li>
</ul>

<h2>Railway, Strapi Cloud, or another host?</h2>
<p>Railway gives you control over the application service, database, variables, and storage choices. That control also gives you responsibility for deployment settings, backups, updates, and incident response. Strapi Cloud packages more of that operational work into a managed service. Compare both against the application's data, recovery, region, scale, and team-ownership requirements rather than choosing from the monthly price alone.</p>
<p>Read the <a href="/blog/strapi-cloud-vs-self-hosting">Strapi Cloud vs. self-hosting comparison</a> for that decision, or review <a href="/services/strapi-development">Strapi development services</a> if you need help with content models, integrations, deployment, or maintenance.</p>

Deploy Strapi on Railway with PostgreSQL, persistent uploads, production secrets, verification steps, backups, and recovery planning.

DevOps Articles