<p>A sandbox is a developer environment. I use it to change data models and functions without treating each experiment as a production release. Production begins when the repository branch, backend stack, generated client configuration, and operational checks point to the same approved commit.</p><p>The risky part of an Amplify Gen 2 sandbox-to-production move is environment confusion. A frontend can build cleanly while using an <code>amplify_outputs.json</code> file generated by another sandbox. My release process proves the identity of the backend before and after deployment.</p>

<h2>Know what the sandbox owns</h2>

<p>A cloud sandbox uses local AWS credentials and creates developer-scoped resources. I give each sandbox a recognizable identifier, inspect the account and region, and avoid using production data. The sandbox is disposable unless I have documented a reason to retain a resource.</p><p>I run the app against the sandbox and test the changed model, function, or authorization rule. Passing local checks means the code is ready for branch validation. It does not mean the sandbox should be promoted as production infrastructure.</p>

<h2>Regenerate and inspect client outputs</h2>

<p>The outputs file tells the frontend which backend endpoints and identity resources to use. I regenerate it for the target environment rather than copying a remembered file. The <a href="https://docs.amplify.aws/react/deploy-and-host/fullstack-branching/branch-deployments/">Amplify fullstack branch deployment documentation</a> documents <code>npx ampx generate outputs</code> for a deployed branch.</p><p>I compare the app ID, branch, region, and expected auth/data sections. I keep secrets out of the file and out of source control. A mismatch here often appears as a 401, DNS error, empty list, or login against the wrong user pool.</p>

<h2>Make the production branch explicit</h2>

<p>I connect a named production branch and document which branch is allowed to update production resources. Feature and staging branches remain isolated. Automatic branch detection can help, but its patterns deserve review so an arbitrary branch cannot acquire production-like permissions.</p><p>Environment variables and secrets are set for the branch that consumes them. I do not assume values from a local shell will exist in the hosted build.</p>

<h2>Run the same preflight every time</h2>

<p>My preflight includes type checking, linting, focused tests, the full test suite, and a production build. I review the Git diff and confirm generated artifacts are expected. If the backend change modifies authorization or data shape, I add a request that proves both allowed and denied behavior.</p><p>I record the commit hash with the results. A list of green commands without the commit cannot prove which code passed.</p>

<h2>Verify the deployment as a user</h2>

<p>After Amplify reports success, I check the deployed commit and request important routes. I sign in with a production test account, read and mutate a safe record, and inspect function logs for errors. Public routes get an anonymous check as well.</p><p>I also confirm that staging and production have separate endpoints and data. A quick success response is not enough if the request reached the wrong environment.</p>

<h2>Keep cleanup and rollback in the release</h2>

<p>I remove unused sandbox resources after the work is merged, subject to the retention policy. For production I document the prior frontend commit, backward compatibility of the backend change, and the restore source for data.</p><ul><li>Identify the AWS account and region.</li><li>Generate outputs for the target branch.</li><li>Run checks against the release commit.</li><li>Verify live identity and data.</li><li>Remove obsolete sandbox resources.</li></ul>

<h2>Need help with Amplify?</h2>

<p>If your Amplify environments have drifted or a production release keeps pointing at the wrong backend, Terry Hunt Dev offers <a href="/services/aws-development">AWS development and deployment support</a>. Share the branch model and failure symptoms through the <a href="/contact">contact page</a>.</p>

Move an Amplify Gen 2 app from sandbox to production with checks for generated outputs, branch configuration, tests, deployment, and live data access.

Moving an Amplify Gen 2 App from Sandbox to Production

Move an Amplify Gen 2 application from a personal sandbox to production without mixing backend outputs, secrets, or branch data.

<p>My website development process starts with the business problem and the person trying to solve it. I need to know who uses the site, which action matters, what information already exists, and what the owner can maintain after launch. The discovery call gives me inputs; written requirements create the project.</p><p>I do not promise a schedule or platform before identifying content, integrations, approvals, and ownership constraints.</p>

<h2>Turn discovery into requirements</h2>

<p>I write the audiences, important journeys, content sources, integrations, accessibility needs, search requirements, analytics boundaries, and operational constraints. Open questions receive owners and dates.</p><p>The client reviews this summary because a polished proposal built on a misunderstood requirement wastes more time than another discovery question.</p>

<h2>Define scope and acceptance</h2>

<p>Each deliverable states what it includes, what it excludes, who supplies content, and how we will verify it. A contact form, for example, includes validation, delivery behavior, error states, and a monitored recipient.</p><p>I separate launch requirements from later ideas. The backlog preserves good ideas without letting them expand the active project.</p>

<h2>Choose architecture from the work</h2>

<p>I select the CMS, frontend, hosting, data, and integration approach after the workflows are clear. Editing frequency, custom functionality, security ownership, budget, and maintenance skill all affect the choice.</p><p>I record tradeoffs. A managed platform may reduce operations while limiting customization; a custom stack creates more control and more ownership.</p>

<h2>Build in reviewable increments</h2>

<p>I deliver a working path early: one real page, one content type, or one integration in a review environment. The client can evaluate structure and behavior before the same pattern spreads across the site.</p><p>Review notes become tracked decisions. I avoid collecting conflicting feedback across email, chat, and unrecorded calls.</p>

<h2>Prepare and run launch</h2>

<p>The preflight covers content approval, redirects, metadata, accessibility checks, forms, analytics consent, backups, security headers, performance, and ownership. I record the release commit and rollback path.</p><p>After deployment I check important routes, forms, structured data, monitoring, and the deployed commit. Search tools and analytics may need later verification because their data does not update at launch time.</p>

<h2>Hand off support</h2>

<p>The owner receives account inventory, deployment notes, backup and recovery steps, content guidance, and maintenance scope. Temporary access is removed or converted into an ongoing support role.</p><ul><li>Requirements are approved in writing.</li><li>Scope has acceptance checks.</li><li>Architecture records tradeoffs.</li><li>Review happens in increments.</li><li>Launch and ownership are verified.</li></ul>

<h2>Need help putting this into practice?</h2>

<p>Terry Hunt Dev provides <a href="/services">website and application development services</a> for teams that need clear technical ownership. Share the business problem and current systems through the <a href="/contact">contact page</a>.</p>

See my website development process from discovery and written requirements through scope, implementation, review, deployment, and maintenance handoff.

Website Development Process: Discovery to Deployment

Turn a business problem into written requirements, reviewable increments, acceptance checks, deployment, and documented ownership.

My Process from Discovery Call to Website Deployment

<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>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.

Deploy Strapi on Railway with PostgreSQL

How to Deploy Strapi on Railway with PostgreSQL

<p>A secure Strapi deployment on AWS starts with boundaries and ownership. The application needs compute, a database, persistent media, secrets, logs, backups, and a recovery path. The exact AWS services can vary; the controls should remain explicit.</p>

<h2>Choose the smallest supportable architecture</h2>
<p>A common design places a public load balancer in front of private application compute. The database stays private. Uploaded media lives in durable object storage rather than an instance filesystem. Use managed services when they remove work your team cannot reliably perform, not simply because an architecture diagram has room for them.</p>

<h2>Use workload identity</h2>
<p>Give the Strapi workload an IAM role with only the actions and resources it needs. Do not create a long-lived administrator access key for the application. Separate deployment permissions from runtime permissions, and test that the application cannot list or change unrelated resources.</p>

<h2>Protect network paths</h2>
<p>Expose HTTPS through the load balancer or edge service. Restrict the application port to the load balancer. Restrict the database to the application security group. Administrative access should use a controlled management path with logging and strong authentication rather than an open SSH rule.</p>

<h2>Store secrets outside the repository</h2>
<p>Keep Strapi application keys, admin JWT secrets, database credentials, provider tokens, and email credentials in an approved secret service or deployment environment. Define who can read and rotate each value. A rotation plan must account for sessions and deployments that depend on the old value.</p>

<h2>Make data durable</h2>
<p>The database and uploaded media need separate backup plans. Record retention, encryption, cross-account or cross-region requirements, and restore steps. Run a restore in a non-production environment. A successful backup job does not prove that the content, relations, users, and media can be recovered together.</p>

<h2>Harden the application</h2>
<p>Review Strapi public roles, administrator roles, API tokens, CORS, proxy settings, upload limits, and enabled plugins. Patch Strapi, Node, dependencies, and the base image through a staged release process. Disable unused endpoints and avoid logging request bodies or secrets.</p>

<h2>Monitor user-visible outcomes</h2>
<p>Collect load balancer, application, database, and deployment signals. Alert on failed requests, elevated latency, resource exhaustion, backup failures, and certificate or domain problems. Keep logs useful without storing content or credentials that the team does not need for diagnosis.</p>

<h2>Verify before launch</h2>
<ul><li>Anonymous and authenticated API permissions match the content model.</li><li>The database and media are not public.</li><li>The workload role cannot access unrelated resources.</li><li>Backups restore into a clean environment.</li><li>A prior application version can be redeployed.</li><li>Owners exist for alerts, patches, and incidents.</li></ul>

<p>Use current <a href="https://docs.strapi.io" rel="noopener noreferrer">Strapi documentation</a> and <a href="https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html" rel="noopener noreferrer">AWS security guidance</a> for the chosen services. For implementation help, review <a href="/services/strapi-development">Strapi development services</a> or <a href="/contact">request an architecture review</a>.</p>

Plan a secure Strapi deployment on AWS with private data services, workload roles, managed secrets, persistent media, backups, monitoring, and patching.

Secure Strapi Deployment on AWS Checklist

Plan a Strapi deployment on AWS around network boundaries, workload identity, database and media recovery, secret handling, observability, and updates.

Deployment Resources & Benchmarks

Moving an Amplify Gen 2 App from Sandbox to Production

My Process from Discovery Call to Website Deployment

Using Codex Safely in a DevOps Deployment Workflow

How to Deploy Strapi on Railway with PostgreSQL

Secure Strapi Deployment on AWS: Architecture Checklist

Need hands-on help with Deployment?