<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 hosting recommendation becomes stale when providers merge, pricing changes, or a framework drops support. Choose hosting from the application's requirements and the team's ability to operate it. A brand list cannot make that decision for you.</p>

<p>Endurance International Group combined with Web.com to form Newfold Digital in 2021, so an article framed around avoiding “EIG hosts” no longer describes the current company structure. Provider ownership is still worth checking, but it is not a substitute for testing the service you may buy.</p>

<h2>Write the runtime requirements</h2>
<p>List the framework and version, server runtime, database, storage, background work, email, scheduled jobs, regions, traffic pattern, and compliance constraints. Confirm each required feature in current provider documentation. “Supports Next.js” is less useful than support for the routes, image handling, streaming, and revalidation modes your application uses.</p>

<h2>Assign operational ownership</h2>
<p>Managed hosting reduces some infrastructure work, but your team still owns application releases, access, data handling, and incident decisions. Self-hosting gives you more control and more systems to patch, monitor, back up, and restore. Write a name beside each responsibility before comparing prices.</p>

<h2>Test deployment and rollback</h2>
<p>Deploy a representative branch with the real build command. Test a static page, a dynamic page, an API route, an image, a form, and an error path. Record build time, warnings, cold response behavior, logs, and the deployed commit. Then roll back to the prior artifact. A smooth signup flow does not prove recovery works.</p>

<h2>Check data and backup boundaries</h2>
<p>Identify where the database, uploads, secrets, logs, and backups live. Confirm retention, encryption, export paths, and restore steps. A provider snapshot helps only if it covers the required data and you can restore it within the business's recovery window.</p>

<h2>Compare support with evidence</h2>
<p>Read the service status history, support scope, escalation channels, and response commitments for the actual plan. Search for documentation on your runtime and failure modes. Reviews can reveal patterns, but they rarely describe the same application, plan, region, and date.</p>

<h2>Calculate the ownership cost</h2>
<ul><li>Monthly platform, database, storage, and transfer charges</li><li>Paid add-ons and support plans</li><li>Engineering time for releases and incidents</li><li>Backup storage and restore testing</li><li>Migration cost if requirements change</li></ul>

<p>Shortlist two options and run the same small deployment on both. The better host is the one that meets the requirements with an operating model the team can sustain. For a framework-specific comparison, read <a href="/blog/aws-amplify-vs-vercel-nextjs">AWS Amplify vs. Vercel for Next.js</a>, or <a href="/contact">share your current architecture</a> for a scoped review.</p>

Evaluate website hosting with a practical checklist for runtime support, backups, recovery, deployment, observability, data location, and cost.

Website Hosting Checklist for Business Sites

Use requirements, recovery ownership, support evidence, and a small deployment test to choose hosting for a business website.

Railway Resources & Benchmarks

How to Deploy Strapi on Railway with PostgreSQL

How to Evaluate Website Hosting Without Chasing Brand Lists

Need hands-on help with Railway?