Leaving Render's Free Tier: When It Makes Sense, and How to Move to a Docker Host

Render's free tier is one of the better ones left, and for a lot of projects it is the right place to stay. This is a guide for the cases where it stops fitting: several small services, a database older than 30 days, or an app that needs more than a tenth of a CPU. It covers when a move makes sense, when it does not, and the exact steps to land on a Docker host.

What Render's free tier gives you, precisely

• A free web service has 512 MB of RAM and 0.1 CPU.
• 750 free instance hours per workspace per month, shared by all your free services. One service running around the clock uses 720 of them.
• Free services spin down after 15 minutes without traffic and take about a minute to come back.
• Free PostgreSQL is 1 GB and expires 30 days after creation, with a 14-day grace period before it is deleted.
• Free custom domains and free static sites. Both are genuinely good.

When to stay on Render

Stay if you run one service that should be reachable most of the time, you want a custom domain for free, or your site is static. The 750 hours cover one always-available service, and nothing in this guide beats a free custom domain.

When a move makes sense

• Several services. An API, a worker and an admin tool cannot all stay inside 750 shared hours. On SnapDeploy the free tier is 4 containers with 100 container-hours a month between them, and hours only count while a container is awake. Four occasionally visited services fit; one always-on service does not.
• CPU. 0.1 CPU is enough for a static-ish site and painful for anything that renders or builds per request. A free SnapDeploy container has 0.25 vCPU and the same 512 MB.
• The database clock. If you have already recreated a free Postgres once because it expired, you are spending time to avoid a bill. A SnapDeploy PostgreSQL Mini is $29/month and does not expire; Neon's free plan (0.5 GB, 100 compute-hours) is the free alternative.
• Docker already. If your service runs from a Dockerfile, the move is a copy, not a rewrite.

What you give up: the free custom domain (on SnapDeploy custom domains need Always-On, $12/month), and Render's larger monthly hour budget for a single service. Sleeping behaves the same on both: 15 minutes idle, about a minute to wake.

Step 1: turn the Render config into a Dockerfile

Render knows your app through the dashboard or a render.yaml: a build command and a start command. A Dockerfile says the same thing in a form every container host understands. A typical Node service:

# render.yaml (before)
services:
  - type: web
    name: api
    runtime: node
    buildCommand: npm ci
    startCommand: node server.js

# Dockerfile (after)
FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
ENV NODE_ENV=production
EXPOSE 3000
CMD ["node", "server.js"]

Python services map the same way: pip install -r requirements.txt in the build stage, the Gunicorn or Uvicorn line as the CMD. If you would rather not write one, SnapDeploy generates a Dockerfile for Node.js, Python, Java, Go, PHP, Ruby and static sites from the repository itself.

One habit to keep from Render: read the port from the PORT environment variable. Both platforms set it.

Step 2: move the environment variables

Open the service on Render, go to Environment, and copy each key and value into the container's environment variables on SnapDeploy. Do it by hand rather than through a shared .env file in the repository; secrets in Git are the mistake that outlives every migration. Values Render injects for you, such as RENDER_EXTERNAL_URL, will not exist on the other side, so search the code for RENDER_ before you switch.

Step 3: move the database

Render gives every Postgres an external connection string (the Connect button on the database page). Dump with it, restore into the new database, and point DATABASE_URL at the new one:

pg_dump --no-owner --no-privileges "$RENDER_EXTERNAL_DB_URL" > backup.sql
psql "$NEW_DATABASE_URL" < backup.sql

Run the app against the new database for a day before you delete the old one. If the free Render database is close to its 30-day expiry, do this step first; everything else can wait, the data cannot.

Step 4: deploy and cut over

1. Push the Dockerfile to the repository.
2. On SnapDeploy: Containers, Deploy from GitHub, pick the repository, add the environment variables, deploy. The first build takes a few minutes.
3. Test on the containers.snapdeploy.app URL: login, one write to the database, one background job if you have one.
4. If the app had a custom domain on Render, decide now: keep the free Render service for the domain, or take Always-On ($12/month) on SnapDeploy and point the domain's A record at the address shown in the container's domain settings.
5. Suspend the Render service rather than deleting it for a week. Going back is cheap when the old thing still exists.

The three things that break on every move

• The port. Hard-coded 10000 (Render's default) instead of process.env.PORT. Symptom: the build succeeds, the container never becomes healthy.
• Trusted hosts and origins. Django's ALLOWED_HOSTS, Rails' config.hosts, Express behind a proxy without trust proxy. Symptom: 400s or CSRF failures on the new hostname.
• Disk. Anything written to the local filesystem on Render's free tier was already ephemeral, but SQLite files and upload folders surface as "data loss" the first time the new container restarts. Use a database and object storage.

If you decide to pay instead

Sometimes the right answer to "I have outgrown the free tier" is a small bill, not a migration. Compare the two cheapest always-on options honestly:

For one always-on service, Render is cheaper. The SnapDeploy case is a paid service plus several free ones next to it, or a service that needs the database add-ons in the same place. Pick by the shape of your project, not by the headline price.

Cut-over checklist

1. Dockerfile builds and runs locally with docker run -p 3000:3000 -e PORT=3000 ….
2. Every environment variable from Render's Environment tab exists on the new container, with the RENDER_ ones replaced.
3. Database dumped, restored, and the app has run against the new one for a day.
4. Health endpoint returns 200 on the new URL.
5. Outbound integrations (webhooks, OAuth callbacks, email providers) updated to the new hostname.
6. Custom domain decision made; DNS TTL lowered a day before the switch if you move it.
7. Render service suspended, not deleted, for a week.