Migrating off Strapi Cloud: Free Plan Removed – Hosting & Migration Guide

Strapi announced on July 21, 2026 that it will sunset the free Strapi Cloud plan (built-in hosting). As of July 1, 2026, new signups can no longer create free projects, and existing free projects will be deleted on September 1, 2026 unless upgraded. Strapi will focus on paid Cloud plans (Starter at $29/month, Pro, Business).

This change affects only Strapi Cloud (the *.strapiapp.com managed hosting). Developers using the open‑source Strapi Community Edition (self-hosted) are unaffected and still free (MIT license). In practice, free-tier users (often hobbyists or startup MVPs) must now either pay or migrate their Strapi backends to other hosts. Production teams already on paid plans continue as normal.

This article explains the impact on different users and gives detailed migration steps. It compares three hosting options (Render, Railway, DigitalOcean VPS) including costs, pros/cons, and step-by-step commands. We also cover database migration (keeping or moving your PostgreSQL), environment variables updates for Next.js/Strapi, rollback/testing tips, and preserving uploaded media.

timeline
    title Migration Timeline
    2026-07-01 : New free projects disabled
    2026-07-21 : Strapi announces free plan removal
    2026-08-01 : Plan migration and hosting choice
    2026-08-15 : Deploy Strapi on new host (Render/Railway/VPS)
    2026-08-16 : Test APIs, data integrity
    2026-08-20 : Cutover DNS/CNAME to new Strapi
    2026-09-01 : Old free projects deleted

Who’s Affected (Cloud Free users) vs. Unaffected (Self-Hosted)

• Affected: Any project running on Strapi Cloud’s free plan (i.e. the Strapi-managed *.strapiapp.com domain) must migrate or upgrade. These free projects are on sleeping containers and have now lost their “free tier”. For example, a URL like https://your-project-id.strapiapp.com is on Strapi Cloud.

• Unaffected (Safe): Anyone self-hosting Strapi (Community Edition) is unaffected. The open-source Strapi CMS (MIT-licensed) is still fully free. Paid Strapi Cloud customers are also unaffected (nothing changes on their accounts).

Put simply: if your backend API URL is *.strapiapp.com or you signed up through Strapi Cloud, this change impacts you. If you run Strapi on your own server (DigitalOcean, Render, Railway, etc.), you can continue as-is.

Impact Assessment: Hobbyists vs Startups vs Production

• Hobbyists/Students: Lose a free forever cloud instance. They now must either self-host (zero cost) or pay ~$29/mo. This is a significant change, but many hobbyist apps can run on free tiers of Render or Railway (or a small VPS).

• Startups/Small Projects: The cost of using Strapi Cloud increases (starter $29/mo vs. $0). However, these teams often prefer reliability and may accept a budgeted $20–30/mo expense. Free alternatives (Render, etc.) exist but have limitations (sleeping, limited compute).

• Production Teams: If you were in a production paid plan, this is a non-event (you’re already paying). But teams must ensure their dev/test setups (if on free tier) migrate. Uptime and features improve under paid plans – free-tier projects on Strapi Cloud had sleeping containers that caused slow startups, which gave a poor experience. Upgrading or moving to a paid host avoids these issues.

Key Factors: Cost vs. Performance. Free Strapi Cloud was $0 but had sleepy performance (the first API call was slow due to “wake up”). Paid plans or other hosts cost money, but offer full uptime and features. Weigh your needs: static-website use (e.g. Next.js pre-render) may tolerate a small cold-start delay, while dynamic apps or teams may need always-on servers. Also consider data persistence: free hosts may not preserve file uploads across restarts (unlike paid or self-hosted setups with persistent disks or object storage).

Migration Options (Step-by-Step)

All our recommendations reuse your existing Strapi code and (if possible) your PostgreSQL data, minimizing rewriting. In each case you will:

• Clone or push your Strapi project to the new host (GitHub/GitLab can integrate to deploy).

• Configure the database (connect to Neon or new Postgres, see DB section).

• Set environment variables (DB credentials, Host, Cloudinary keys, etc.).

• Deploy and test, then point your frontend (Next.js) to the new API URL.

Below we detail three hosts: Render (highly recommended), Railway, and a DigitalOcean Droplet (VPS). Each includes pros/cons, cost estimates, downtime risk, and commands/snippets.

1. Render.com (Recommended)

Why Render? Render offers a free tier for web services and Postgres, with managed TLS and zero-downtime deploys. It auto-restarts crashed apps and supports custom domains and pull-request previews. It’s easy: connect your Git repo, click “New Web Service”, and configure builds.

• Pros: Free 750 instance-hours/month (so ~free for hobby use). Auto HTTPS (free certs), built-in Postgres DB, automatic restarts. Easy Git deploys and YAML config support.

• Cons: Free web services sleep after 15 minutes idle (you’ll see a short cold-start delay on first API call). Free Postgres DBs expire after 30 days (you should promote to a paid DB or connect your own Neon).

• Cost: Free for low usage (no credit card needed). A basic paid plan (Standard 1x) is ~$7–10/mo; managed Postgres starts around $0 for db (or ~$15/mo for more). You pay as you scale.

• Downtime Risk: Very low for paid instances (automatic restarts). Free tier downtime is only cold-start delay, no loss of data on restart if using managed Postgres. If scaled, you can do rolling deploys for zero downtime.

Render Migration Steps (summary):

1. Sign up / Login to Render and connect your GitHub/GitLab repo (or use render login CLI).

2. Create Postgres: In Render Dashboard, click “New Database” → Postgres. Choose a plan (free starter for testing). Note the connection info or create a Secret (host, DB, user, password).

3. Create Web Service: Click “New Web Service”. Select your repo and branch. In Environment, choose Node 18/20, and enter build/start commands (e.g. npm install && npm run build, start npm start).

4. Environment Variables: In Render, go to the service’s Settings → Environment. Add variables like DATABASE_HOST, DATABASE_NAME, DATABASE_USERNAME, DATABASE_PASSWORD, and any Cloudinary keys or Strapi secrets. For example:
   

   DATABASE_HOST=your-postgres-host.render.com
   DATABASE_PORT=5432
   DATABASE_NAME=render_db
   DATABASE_USERNAME=render_user
   DATABASE_PASSWORD=securepass
   DATABASE_SSL=true
   APP_KEYS=...        # from Strapi .env
   API_TOKEN_SALT=...
   ADMIN_JWT_SECRET=...
   

5. Deploy: Click “Create Web Service”. Render will build and deploy your Strapi app. Check the Logs for any errors.

6. Test: Once live (you’ll get a default *.onrender.com URL), try curl https://your-app.onrender.com/api/your-endpoint. Also test the Strapi Admin UI at https://your-app.onrender.com/admin.

7. DNS Cutover: When satisfied, update your domain (or Next.js config) to use https://your-app.onrender.com (or custom domain) instead of the old Strapi Cloud URL. Ensure front-end env var change as in the Env Vars section below.

8. Cleanup: Once fully migrated, delete the old Strapi Cloud free project to avoid duplicate usage.

Render Checklist:

• Create Render Postgres and get credentials.

• Push Strapi code to Git if not already.

• Connect Render Web Service to repo; configure build & start.

• Set Render Env Vars (DB + Strapi secrets + Cloudinary keys if used).

• Deploy and check that npm run build && npm run start works.

• Test API and Admin, then switch frontend URL.

2. Railway.app

Why Railway? Railway provides an easy “deploy from Git” or CLI experience with a built‑in Postgres. It’s great for prototypes. It even offers a Strapi+Postgres template.

• Pros: Extremely simple startup. You can just railway up or use the template, and Railway will auto-create a Postgres. It provides an interactive CLI for setup. Includes private networking by default, and SSL endpoints.

• Cons: Limited free usage. New accounts get a 30-day trial with $5 credit (roughly $0.07 CPU-hour cost). After that, you need a Hobby or Pro plan (~$1/month baseline for minimal usage). There is no always-free web service beyond the trial credits. Also, some report that Railway projects “sleep” (the docs don’t explicitly say, but it’s similar to Render/Heroku).

• Cost: Free trial ($5 credit) then ~$1/month minimum (Hobby plan) for a 0.5GB, 1 vCPU service. Paid plans (Hobby or Pro) may be needed for production or longer uptime.

• Downtime Risk: Similar to Render’s free tier, small services may cold-start. No guaranteed SLA on free tier. On Hobby/Pro plan, Railway promises 99.9–99.99% uptime.

Railway Migration Steps (summary):

1. Sign up/Railway Login: Register at Railway.app and authorize your Git repo.

2. Create Project: Click “New Project” and select “Deploy from GitHub” (or use the Strapi template). If using CLI: install railway CLI, run railway login and railway init in your Strapi project folder.

3. Provision Postgres: Railway might auto-create a PostgreSQL for you (via template). Or click “Add Service” → Postgres. Note the DB connection URL Railway provides.

4. Set Environment Variables: In Railway’s Project Settings (or via CLI with railway variables set), define:
   

   DATABASE_URL=postgresql://railway_user:[email protected]:xxxxx/railway_db
   NODE_ENV=production
   APP_KEYS=...
   API_TOKEN_SALT=...
   ADMIN_JWT_SECRET=...
   

   (Railway sets up DATABASE_URL automatically if using their DB). If not using DATABASE_URL, set DATABASE_HOST, etc, similar to Render.

5. Deploy Strapi: If using the template, Railway may auto-deploy. If manual: push to Git or use railway up. Check logs. Railway will run npm install and npm start.

6. Test and Promote: Once deployed, test endpoints at https://your-project-production.up.railway.app. Confirm Admin UI (/admin) works.

7. Switch Frontend: Update your Next.js NEXT_PUBLIC_STRAPI_URL to Railway’s URL.

8. Rollback/Tips: If something fails, you can edit and railway redeploy, or use the Railway dashboard to rollback.

Railway Checklist:

• Initialize Railway project (web + Postgres).

• Configure Strapi start command (usually npm run start).

• Set Railway environment variables (DB URL & Strapi secrets).

• Ensure port 1337 (Railway uses dynamic ports, but Strapi listens on process.env.PORT or 1337 by default).

• Deploy and test API.

• Swap to Railway URL in front-end.

3. DigitalOcean Droplet (VPS)

Why DigitalOcean? A traditional VPS (Droplet) gives full control. It has no idle-sleep and is very stable. You also learn DevOps (Node/PM2/Nginx).

• Pros: Complete control (SSH, firewall, backups, etc.). No enforced “sleep”; always running. Can attach block storage or spaces. Very cost-effective ($6–12/mo for a basic Droplet). Good for production with SLAs.

• Cons: You manage the server: OS updates, firewalls, SSL, PM2/Nginx, etc. More initial work and maintenance. There's no free tier (only some new-user credit).

• Cost: Droplet (1 vCPU, 1–2GB RAM) starts at $6/month. You’ll also possibly pay for a managed DB ($15/mo) or run Postgres on the same droplet. Domain/DNS is extra if needed.

• Downtime Risk: Low if configured well. A single Droplet might restart occasionally or crash, but PM2 auto-restarts the app. You can add a second Droplet for redundancy (beyond scope here).

DigitalOcean Migration Steps (Ubuntu 22.04 example):

1. Create a Droplet: Log into DO, “Create Droplet” → choose Ubuntu 22.04, at least 2GB RAM (Strapi needs ~2GB to build). Add your SSH key. Note the droplet’s IP.

2. Server Setup: SSH into it.
   

   ssh root@your_server_ip
   

*   Create a new user (e.g. `sammy`) and give it sudo (as per DO’s [Initial Server Setup](https://docs.digitalocean.com/tutorials/initial-server-setup-ubuntu-22-04/)).

1. Install Node.js:
   

   sudo apt update
   curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
   sudo apt install -y nodejs build-essential
   

   (Strapi recommends Node 18 LTS for v4/5).

2. Clone Strapi Project: On the server (as your new user):
   

   cd ~
   git clone https://github.com/your-username/your-strapi-repo.git
   cd your-strapi-repo
   npm install
   npm run build
   

3. Configure Database: You have two choices:

*   **Use Neon (no migration):** Simply use the same Neon Postgres you had. Update Strapi’s config or `.env` with the Neon connection string (see \[Integrate Neon with Strapi\]\[35\], or simply set `DATABASE_URL=postgresql://user:pass@neon_host/dbname?sslmode=require`). Strapi can connect to Neon from any host.

*   **Use local Postgres:** Install Postgres on the Droplet:

    ```shell
    sudo apt install -y postgresql postgresql-contrib
    sudo -u postgres createdb strapidb
    sudo -u postgres createuser --interactive  # make a user (e.g. 'sammy')
    # Set password:
    sudo -u postgres psql -c "ALTER USER sammy PASSWORD 'your-password';"
    ```

    Update `config/database.js` (or environment) in Strapi to use that DB (example snippet).

1. Set Environment Variables: Create a .env file or export variables. For example:
   

   cd ~/your-strapi-repo
   cat <<EOF > .env
   DATABASE_HOST=localhost
   DATABASE_PORT=5432
   DATABASE_NAME=strapidb
   DATABASE_USERNAME=sammy
   DATABASE_PASSWORD=your-password
   DATABASE_SSL=false
   APP_KEYS=...your-app-keys...
   API_TOKEN_SALT=... 
   ADMIN_JWT_SECRET=... 
   JWT_SECRET=...
   CLOUDINARY_NAME=...
   CLOUDINARY_KEY=...
   CLOUDINARY_SECRET=...
   EOF
   

   (Adjust Cloudinary keys or S3 as needed).

2. Install PM2:
   

   sudo npm install -g pm2
   

   Create ecosystem.config.js (in your Strapi project root) as per [27†L452-L461], for example:
   

   module.exports = {
     apps: [
       {
         name: 'strapi',
         cwd: '/home/sammy/your-strapi-repo',
         script: 'npm',
         args: 'start',
         env: {
           NODE_ENV: 'production',
           DATABASE_HOST: 'localhost',
           DATABASE_PORT: '5432',
           DATABASE_NAME: 'strapidb',
           DATABASE_USERNAME: 'sammy',
           DATABASE_PASSWORD: 'your-password',
         },
       },
     ],
   };
   

   Then start Strapi with PM2:
   

   pm2 start ecosystem.config.js    # [27†L477-L482]
   pm2 save
   pm2 startup                    # set PM2 to launch on reboot [27†L528-L536]
   

3. Configure Nginx and SSL:

*   Install Nginx: `sudo apt install -y nginx`

*   Create an Nginx server block for your domain:

    ```nginx
    server {
        listen 80;
        server_name your-domain.com www.your-domain.com;
        location / {
            proxy_pass http://127.0.0.1:1337;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }
    }
    ```

    Save as `/etc/nginx/sites-available/strapi` and `sudo ln -s /etc/nginx/sites-available/strapi /etc/nginx/sites-enabled/`.

*   Test Nginx and reload:

    ```shell
    sudo nginx -t && sudo systemctl reload nginx
    ```

*   **SSL (Let’s Encrypt)**:

    ```shell
    sudo apt install -y certbot python3-certbot-nginx
    sudo certbot --nginx -d your-domain.com -d www.your-domain.com
    ```

    Certbot will automatically edit the Nginx config to add SSL. (See \[27†L565-L574\]\[27†L599-L608\]).

1. Test: Visit https://your-domain.com/admin. You should see the Strapi login (running in production mode). Use curl to test an API route:
   

   curl https://your-domain.com/api/your-endpoint
   

Droplet Checklist:

• Droplet with Ubuntu set up and user created.

• Node and Strapi built (npm run build).

• PostgreSQL ready and Strapi connected to DB.

• PM2 configured (ecosystem.config.js and pm2 start).

• Nginx configured as reverse proxy and SSL enabled.

• Front-end env var updated to https://your-domain.com.

Database Migration Options

If your data lives in a PostgreSQL database, you have choices:

1. Keep using NeonDB (no change). If you currently use Neon (or any external DB), you can simply point your new Strapi host to it by setting DATABASE_URL (or host/user/pass) to Neon’s details. Strapi supports Neon out of the box (just include ?sslmode=require for Neon).

2. Use a new Postgres and import data. If you switch to a different Postgres (e.g. Render’s or a Droplet’s DB), migrate your data:

*   On a machine with `pg_dump`/`pg_restore`, run:

    ```shell
    pg_dump -h old_host -U old_user -d old_db -Fc > backup.dump
    pg_restore -h new_host -U new_user -d new_db -v backup.dump
    ```

    *(These commands produce a compressed dump and restore it to the new DB.)* For example, Neon’s docs show pg\_dump/pg\_restore usage for migrating between Postgres instances. You may need to allow network access or use SSH to run these between servers.

*   **Alternatively**, use Strapi’s Data Import plugins or CSV/JSON export-import tools (but pg\_dump is simplest for Postgres).

*   After restoring, ensure your new DB user has privileges (grant `ALL` on the public schema if needed).

1. Switch DB entirely (no data). If it’s a throwaway demo, you can start with a fresh DB and not migrate data (just set up content types and seed initial data manually).

Connection Strings: You can use an environment variable for the full URL:

DATABASE_URL=postgresql://user:password@host:5432/dbname?sslmode=require

Or the discrete variables shown earlier. Strapi will use whichever you configure in config/database.js. For Next.js, the only DB change is in Strapi (Next.js calls Strapi via HTTP API, not DB).

Updating Environment Variables & API URLs

After migration, your frontend (Next.js) must point to the new Strapi URL. For example, update .env.local in Next.js:

# Before (Strapi Cloud)
NEXT_PUBLIC_STRAPI_URL=https://stunning-hope-921073164a.strapiapp.com

# After migration
NEXT_PUBLIC_STRAPI_URL=https://servd-api.onrender.com

In Strapi, ensure production env vars match the new host/DB. For instance, in config/database.js (or .env):

module.exports = ({ env }) => ({
  connection: {
    client: 'postgres',
    connection: {
      host: env('DATABASE_HOST', '127.0.0.1'),
      port: env.int('DATABASE_PORT', 5432),
      database: env('DATABASE_NAME', 'strapidb'),
      user: env('DATABASE_USERNAME', ''),
      password: env('DATABASE_PASSWORD', ''),
      ssl: env.bool('DATABASE_SSL', false) && { rejectUnauthorized: false },
    },
  },
});

Set those env vars in your host’s dashboard or .env.

Also update any media/storage keys (Cloudinary/S3) in the environment. For example:

CLOUDINARY_NAME=...
CLOUDINARY_KEY=...
CLOUDINARY_SECRET=...

Then redeploy Strapi.

Rollback & Testing

Testing: Before cutting over, thoroughly test the new setup:

• Use Postman/cURL to fetch key API endpoints on the new host.

• Check the Strapi Admin login and basic content functionality.

• Ensure that uploaded files (images) are accessible (test an existing upload URL).

• Have your CI/CD or git branches ready so you can revert changes if needed.

Rollback Plan: Keep the old Strapi Cloud free project unchanged while testing. Do not delete it until migration is final. If the new host fails, you can continue using the old URL (and then pay for a paid plan if needed). Because Strapi Cloud free will be deleted on Sept 1, 2026, you have a window to roll back if something critical breaks – but within that timeframe you could also upgrade the cloud project to a paid plan as a last resort.

Preserving Uploads/Media: Strapi Cloud free stores uploads on its server (which you can’t easily export). To avoid data loss:

• Use an external file storage. The best practice is to configure Strapi to use a provider like Cloudinary or AWS S3 for uploads. Cloudinary has a free tier (1GB) and can be set up with the strapi-provider-upload-cloudinary plugin. This way, media lives in the cloud and is unchanged by server migrations.

• If you already have media in Strapi Cloud, you should manually migrate them. One way is to download all uploads from Strapi Cloud (e.g. via the Strapi Admin or API) and re-upload to Cloudinary/S3, updating the url fields in the database. Or use rsync/scp if you can get direct access (not possible on Strapi Cloud free).

• If using DigitalOcean with attached disk or block storage, you could copy files via SSH between servers.

Rollbacks: Keep your code under version control. If something goes wrong, you can redeploy an older commit or repoint DNS back to the old server. For example:

# If using Render: roll back to a previous deploy (Render supports rollbacks via the dashboard).
# If using Railway: use the UI to revert to a prior deployment.
# If on DigitalOcean: you have a static IP; you could switch Nginx back to the old server block (if you kept it) or shut down the new Droplet.

Have database dumps ready (pg_dump) so you can restore the old DB state if needed.

Additional Tips

• Using SSL: All recommended hosts handle TLS easily: Render/Railway give free HTTPS. For VPS, use Certbot as shown. Always use https:// in NEXT_PUBLIC_STRAPI_URL.

• Environment Modes: Remember Strapi’s admin UI won’t let you edit content-types in production mode. For production on Render/Railway, content types should be finalized before deployment. (Alternatively, have a separate staging branch.)

• Monitoring: Check logs after deployment. Render and Railway provide logs in their dashboards. For Droplet, use pm2 logs and sudo journalctl -u nginx.

• Backups: Schedule regular DB backups. Many managed Postgres (Render, Railway) have snapshots or you can use pg_dump on a cron.

Comparison Table of Hosts