DEV Community: ELIM

Moving from a VPS to Cloud Run: what each piece becomes

ELIM — Wed, 14 Oct 2026 07:08:14 +0000

This guide was first published on exodus.elim.io. Prices are Google's list prices on the date in the text.

Moving from a VPS to Cloud Run puts the app in a container and turns every other piece of the server into a Google service: Postgres into Cloud SQL, uploads into Cloud Storage, crontab into Cloud Scheduler and jobs, nginx into Cloud Run's HTTPS. In our model the bill goes up, from $8.39 to $12.59 a month to $9.59 to $174.52, so move for the work saved.

In short

On price the VPS wins at every size in our model: $8.39 to $12.59 a month on Hetzner against $9.59 to $174.52 on Cloud Run with Cloud SQL.
The systemd unit becomes a Dockerfile; the app listens on PORT, 8080 by default, and finishes within 10 seconds of SIGTERM, where systemd gave 90.
Postgres moves with pg_dump and pg_restore, or with Database Migration Service for versions 9.4 to 18 at no extra charge.
Crontab lines become Cloud Run jobs started by Cloud Scheduler, $0.10 a job a month after 3 free, in the server's time zone rather than UTC.
Requests stop at 32 MiB over HTTP/1 and 60 minutes, and outbound port 25 is blocked.

Prices exclude VAT and are list prices of October 11, 2026.

When moving pays, and when it does not

A VPS is cheap. Hetzner's CX23 in Germany or Finland (2 vCPUs, 4 GB of memory, a 40 GB disk) costs $6.49 a month since Hetzner's price change of June 15, 2026, plus $0.60 for its IPv4 address and 20% of the server price for daily backups, $8.39 in all. The CX33 with 4 vCPUs and 8 GB is $12.59 on the same terms. Both include 20 TB of outbound traffic a month. DigitalOcean's Basic droplet with 1 vCPU and 2 GiB is $12 with 2,000 GiB of traffic included ($14.40 with weekly backups); the one with 2 vCPUs and 4 GiB is $24 ($28.80).

On Google Cloud the same app becomes at least three bills. Cloud Run, with request-based billing in a Tier 1 region such as europe-west1, charges $0.000024 per vCPU-second and $0.0000025 per GiB-second while requests are handled, and $0.40 per million requests, after a free tier of 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests a month per billing account. Traffic to users in Europe is $0.105 per GiB from the first gigabyte (the egress guide has the details). The database becomes Cloud SQL: the shared-core db-f1-micro is $9.37 a month with 10 GiB of disk, the db-g1-small $27.25 (the Cloud SQL guide explains both). Uploads go to Cloud Storage at $0.020 per GiB a month.

One web app with Postgres, on a Hetzner cloud server and on Cloud Run with Cloud SQL in europe-west1, list prices of October 11, 2026, before VAT

The model is one web app with its database, three sizes:

A quiet internal tool: 30,000 requests and 2 GB out a month. The CX23 is $8.39. Cloud Run's part fits in the free tier, traffic is $0.20 and storage $0.02, but the Cloud SQL micro is $9.37: $9.59.
A small app: 1 million requests of 200 ms and 50 GB out. The CX23 handles it, $8.39. On Cloud Run, as an upper bound with no two requests sharing an instance: $0.48 of CPU past the free tier, $4.89 of traffic, the micro at $9.37 and $0.10 of storage, $14.84.
A busy app: 10 million requests and 1 TB out, which still fits a CX33 and its 20 TB of traffic, $12.59. On Cloud Run: $43.68 of CPU, $1.60 of memory, $3.20 of requests, $97.79 of traffic, a db-g1-small at $27.25 because 0.6 GB of memory is too little for a database at this load, and $1.00 of storage, $174.52.

So on price the VPS wins at every size. The database alone on Cloud SQL costs more than a whole Hetzner server, and traffic that the VPS includes is the largest line of the Cloud Run bill. If the bill is the reason to move, do not move.

The reasons to move are the work the server needs: patching the operating system, renewing certificates, restarting after a crash, watching the disk, testing backups. If the one machine fails, the app is down until someone rebuilds it. Cloud Run spreads instances across the zones of a region and keeps running when one zone fails; a deploy creates a revision you can roll back to in one command; Cloud SQL patches Postgres and takes daily backups; a traffic spike starts more instances. Move when that work costs you more than the difference on the bill, when the app has outgrown one machine, or when the rest of your system already lives on Google Cloud. Stay when the load is steady, a lot of data goes out, the app depends on a local disk, or one person runs the server happily. Cloud Run or a VPS weighs that choice in full.

What the server does for you

Start with an inventory, on the server. These commands only read:

systemctl list-units --type=service --state=running --no-pager
systemctl list-timers --all --no-pager
sudo crontab -l -u app; sudo ls /etc/cron.d
sudo nginx -T 2>/dev/null | grep -E 'server_name|proxy_pass|root |client_max_body_size|proxy_read_timeout' | grep -v '#'
sudo ss -tlnp
sudo ls /etc/letsencrypt/live
timedatectl
sudo du -sh /srv/app/uploads /var/log
sudo -u postgres psql -c '\l+'

Replace app with the user the app runs as and /srv/app with its directory. The services list shows the app and anything next to it (a worker, Redis). Timers and crontabs are the scheduled work. The nginx lines give the domain, the upstream port, the static directory, the largest upload and the longest wait. timedatectl gives the time zone the crontab runs in, and the last two lines show how much data moves. We ran the crontab, nginx, ss and psql lines in Debian 13 and Postgres 17 containers set up like a small VPS.

Where each piece of a VPS goes on Google Cloud

Step 1: the app in a container

Cloud Run runs container images, so the app needs a Dockerfile. If the app already runs in Docker on the server, keep its Dockerfile and read this step for the four code changes; a stack under Compose is mapped service by service in Docker Compose to Cloud Run. Otherwise the systemd unit tells you most of what the Dockerfile needs:

# /etc/systemd/system/shop.service
[Service]
User=app
WorkingDirectory=/srv/app
EnvironmentFile=/srv/app/.env
ExecStart=/usr/bin/node server.mjs
Restart=always

WorkingDirectory becomes WORKDIR, ExecStart becomes CMD, User becomes USER. EnvironmentFile does not go into the image; its values become Cloud Run settings in Step 4. Restart=always has no line: Cloud Run replaces instances itself.

FROM node:24-slim
WORKDIR /srv/app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
CMD ["node", "server.mjs"]

Add a .dockerignore with .env, uploads/, logs/, node_modules/ and .git/, so passwords and user files stay out of the image. Other languages follow the same pattern; the buildpacks guide shows how to skip the Dockerfile.

Four things change for the code itself:

The port. Cloud Run sends requests to the port in the PORT variable, 8080 by default, on 0.0.0.0. An app that listens on 127.0.0.1:3000 behind nginx gets --port=3000 at deploy time and must listen on all addresses.
Process managers. pm2 in cluster mode or gunicorn with eight workers filled the machine's cores. On Cloud Run run one process, or one worker per vCPU of the instance, and let Cloud Run add instances; the concurrency guide explains the rest.
Shutdown. Cloud Run sends SIGTERM and kills the container 10 seconds later. systemd waits 90 seconds by default, so a slow shutdown that never mattered now gets cut off. Handle SIGTERM by closing the server and finishing open requests; the Fly guide shows the difference.
The CPU. Cloud Run runs Linux x86_64 images. If you build on an ARM Mac, build with --platform linux/amd64. Cloud Run's second generation execution environment (--execution-environment=gen2, always used by jobs) has full Linux compatibility, so native modules that ran on the VPS run here too.

Then find everything the app writes to disk. Run the image with a read-only file system and a writable /tmp, and every write outside /tmp fails loudly:

docker build -t shop:1 .
docker run --rm --read-only --tmpfs /tmp -p 3000:3000 shop:1

A sample app run read-only in Docker on our machine, October 11, 2026; its image also creates logs/ and uploads/, as the server had them. Stack lines are cut

Cloud Run's file system is writable, so the app would start there; the test only finds the writes, because each written file lives in the instance's memory and disappears with it. Our sample crashed on its log file and, once logging went to stdout, failed on an upload.

Step 2: files on disk

Logs go to stdout and stderr. Cloud Run sends them to Cloud Logging, which stores the first 50 GiB per project a month free and charges $0.50 per GiB after that. Remove the log files, the logrotate config and any log shipping agent.

Uploads go to Cloud Storage. The clean way is to change the code: write each upload to a bucket with Google's client library, and serve it either through the app or with signed URLs. If the code is large and paths are everywhere, Cloud Run can mount a bucket as a directory with Cloud Storage FUSE, once the service exists (Step 5):

gcloud storage buckets create gs://PROJECT_ID-uploads --location=europe-west1
gcloud run services update shop --region europe-west1 \
  --add-volume=name=uploads,type=cloud-storage,bucket=PROJECT_ID-uploads \
  --add-volume-mount=volume=uploads,mount-path=/srv/app/uploads

Google lists its limits: no file locking, two writes to the same file lose all but the last, and it is not a full POSIX file system. Uploads with unique names work; a SQLite database or a file several instances append to does not. The files guide compares this with signed URLs.

Copy the existing files ahead of the move and again during the switch; rsync copies only what changed:

gcloud storage rsync /srv/app/uploads gs://PROJECT_ID-uploads --recursive

That needs gcloud on the server; or rsync the directory to your machine first.

Scratch files in /tmp count against the instance's memory, and filling it crashes the instance. An ephemeral disk for services is in Preview (1 to 100 GiB a volume, 10 GiB an instance by default, deleted with the instance). Files that must outlive a request go to the bucket.

Step 3: the database

Postgres on the server becomes Cloud SQL, a Postgres that Google runs, patches and backs up. Create the instance and the database first (the Cloud SQL guide has the command and the sizes). For a database of a few gigabytes, a dump and a restore during a short write freeze is enough. Postgres on a VPS usually listens only on localhost, so dump on the server and copy the file:

# on the server, after stopping writes
sudo -u postgres pg_dump -Fc --no-owner --no-acl shop > /tmp/shop.dump
# on your machine
scp app@SERVER:/tmp/shop.dump .

Restore through the Cloud SQL Auth Proxy as the App Platform guide shows, and compare row counts. We ran the same dump and restore between two Postgres 17 containers and got the same 1,234 rows on both sides.

For a larger database, or one that cannot stop for long, Google's Database Migration Service copies a self-managed Postgres (versions 9.4 to 18) and then keeps replicating changes until you switch. It needs the pglogical extension on the server, some settings changed and a Postgres restart, and the server must accept connections from Google. For Postgres to Postgres it costs nothing extra.

On Cloud Run the app connects through a Unix socket. Deploy with --add-cloudsql-instances=PROJECT_ID:europe-west1:shop-db, give the service account the Cloud SQL Client role, and set DATABASE_URL to postgresql://shop:PASSWORD@/shop?host=/cloudsql/PROJECT_ID:europe-west1:shop-db. Two things differ from localhost: each query crosses a network, so pages with hundreds of small queries get slower, and every instance opens its own pool: the micro allows 25 connections, so ten instances with a pool of five already run out. Set --max-instances with that in mind.

Redis on the same server, if the inventory showed one, is a decision of its own. As a cache it can often go away; for queues see the background workers guide, for the rest the patterns guide.

Step 4: secrets and settings

The .env file splits in two. Values that are not secret (NODE_ENV, a bucket name, a public URL) become --set-env-vars. Passwords and keys go to Secret Manager, copied by a pipe so they never appear on the screen or in the shell history:

grep '^STRIPE_KEY=' .env | cut -d= -f2- | tr -d '\n' \
  | gcloud secrets create STRIPE_KEY --data-file=-

If the value is in quotes in the file, add sed 's/^"//; s/"$//' before tr. Check lengths, never values: gcloud secrets versions access latest --secret=STRIPE_KEY | wc -c. We checked the pipe on a sample .env byte by byte.

DATABASE_URL changes, since it now points at the socket. Type the new value without echo and pipe it:

read -rs URL && printf '%s' "$URL" | gcloud secrets create DATABASE_URL --data-file=-

The service account needs roles/secretmanager.secretAccessor on each secret.

Step 5: deploy

Create a service account for the app, then build the image once and deploy it:

gcloud iam service-accounts create shop
gcloud artifacts repositories create shop --repository-format=docker --location=europe-west1
gcloud builds submit --tag europe-west1-docker.pkg.dev/PROJECT_ID/shop/shop:1
gcloud run deploy shop --region europe-west1 \
  --image europe-west1-docker.pkg.dev/PROJECT_ID/shop/shop:1 \
  --service-account=shop@PROJECT_ID.iam.gserviceaccount.com \
  --allow-unauthenticated --port=3000 \
  --cpu=1 --memory=512Mi --max-instances=5 \
  --add-cloudsql-instances=PROJECT_ID:europe-west1:shop-db \
  --set-env-vars=NODE_ENV=production,UPLOAD_BUCKET=PROJECT_ID-uploads \
  --set-secrets=DATABASE_URL=DATABASE_URL:latest,STRIPE_KEY=STRIPE_KEY:latest

The service account needs roles/cloudsql.client and access to the bucket. The output ends with an HTTPS URL on run.app; test everything there before DNS changes. Building from source with gcloud run deploy --source . also works, as the Vercel guide shows, but a tagged image is what the jobs in the next step reuse.

Step 6: cron, timers and the processes next to the app

On a VPS, cron runs a command on the same machine. On Google Cloud the schedule moves to Cloud Scheduler, and the command runs as a job. Take two lines:

15 3 * * * cd /srv/app && node jobs/cleanup.mjs >> logs/cron.log 2>&1
*/5 * * * * curl -fsS http://127.0.0.1:3000/tasks/run

A command becomes a Cloud Run job, from the same image, and a Scheduler job that starts it:

gcloud run jobs deploy cleanup --region europe-west1 \
  --image europe-west1-docker.pkg.dev/PROJECT_ID/shop/shop:1 \
  --command=node --args=jobs/cleanup.mjs \
  --service-account=shop@PROJECT_ID.iam.gserviceaccount.com \
  --set-cloudsql-instances=PROJECT_ID:europe-west1:shop-db \
  --set-secrets=DATABASE_URL=DATABASE_URL:latest
gcloud scheduler jobs create http cleanup-nightly --location=europe-west1 \
  --schedule="15 3 * * *" --time-zone="Europe/Berlin" \
  --uri=https://run.googleapis.com/v2/projects/PROJECT_ID/locations/europe-west1/jobs/cleanup:run \
  --http-method=POST \
  --oauth-service-account-email=shop@PROJECT_ID.iam.gserviceaccount.com

The account Scheduler uses needs roles/run.invoker on the job. Set --time-zone to what timedatectl printed: Scheduler defaults to UTC, and a crontab runs in the server's zone. Run the job by hand once with gcloud run jobs execute cleanup --region europe-west1 --wait.

A call to localhost becomes a Scheduler HTTP job that calls the service's URL. On the VPS, /tasks/run answered only on localhost, but a public Cloud Run service answers everyone on every path. Either move the task into a job like the one above, or have Scheduler send an OIDC token (--oidc-service-account-email) and make the app verify it before it does anything.

systemd timers move the same way. The cron and timers guide has Scheduler's price, retries and overlap traps.

A second process, such as a worker reading a queue under its own systemd unit, becomes a Cloud Run worker pool with no URL (the ECS guide has the command), or a Cloud Tasks queue (the background workers guide compares them). Work the app does after the response needs instance-based billing; the services, jobs and worker pools guide explains why.

Step 7: nginx, the network and the switch

nginx did several jobs, and each one goes somewhere else:

TLS and certbot. Cloud Run serves HTTPS with a certificate Google manages. Remove certbot.
The proxy. Requests reach the container directly. For nginx rules you depend on (rewrites, basic auth), Google documents nginx as a second container in the service.
Static files from root /srv/app/public come from the app, or from a bucket behind a CDN if they are large.
Upload size (client_max_body_size). Cloud Run accepts requests up to 32 MiB over HTTP/1. Larger uploads go straight from the browser to Cloud Storage with a signed URL.
Waiting time (proxy_read_timeout). Cloud Run's request timeout is 5 minutes by default and 60 at most, set with --timeout. WebSocket and SSE connections nginx kept open are covered in WebSockets and SSE on Cloud Run.

Two VPS habits need a decision. A fixed outbound address: if a partner's API allows only your server's IP, note that Cloud Run's address changes. A static one needs a VPC network and a Cloud NAT gateway, and Google warns that with Direct VPC egress this can delay cold starts by 30 seconds or more. Email on port 25: Google Cloud blocks outbound connections to port 25 by default. Send mail through a provider on port 587 or its API.

What changes in a move, from Hetzner's, systemd's and Google's pages of October 11, 2026

The domain. Google offers three ways to put it on Cloud Run: a global external Application Load Balancer (the one Google recommends), Firebase Hosting, or Cloud Run domain mapping, which is in Preview. The Vercel guide compares them and gives the order of the switch: lower the DNS TTL a day before, test on the run.app URL, change DNS, keep the old setup for a week. A VPS adds five steps:

Put the app on the server into maintenance mode, so nothing writes.
Take the final dump and restore it, or let Database Migration Service catch up and promote the new database.
Run gcloud storage rsync for the uploads one last time.
Change DNS, then comment out the crontab and stop the timers on the server, so nightly jobs do not run twice.
Keep the server for a week as the way back. Then take a last backup or snapshot, download it, and delete the server.

What breaks most often

Files written next to the code (logs, uploads, a cache, a SQLite file) that vanish with every new instance.
Code that listens on 127.0.0.1 or ignores PORT.
A shutdown that systemd gave 90 seconds and Cloud Run gives 10.
A crontab moved to Scheduler without its time zone, running an hour or two off.
A localhost-only endpoint that is now public.
Too many database connections once several instances each open a pool.
A partner API that only accepts the old server's IP, or mail sent to port 25.

All of these show up on the run.app URL if you test the jobs, an upload and a sign-in there. The patterns that break on Cloud Run guide covers the rest. For a machine with many services, Google's Migrate to Containers tool turns a Linux VM into container images; for one app, a hand-written Dockerfile is shorter. A Compute Engine VM has its own steps in Compute Engine VM to Cloud Run.

Where Exodus comes in

A VPS rarely keeps its setup in the repository. Exodus's CLI reads what is there (the code, a Dockerfile, deploy scripts, systemd units and nginx configs if committed), and your coding agent reads the code for what the server did implicitly: paths it writes to, localhost calls, port 25, pool sizes. The report lists each piece from the map above with what it becomes, and puts the month on Cloud Run with Cloud SQL next to what the server costs now, traffic included. When the server is cheaper and nothing argues for moving, it says to stay.

FAQ

Is Cloud Run cheaper than a VPS?

Usually not. In our model a Hetzner server costs $8.39 to $12.59 a month with backups and 20 TB of traffic, while the same app on Cloud Run with Cloud SQL costs $9.59 to $174.52. Cloud SQL alone costs more than the whole server, and traffic is the largest line at scale.

How do I move cron jobs from a VPS to Cloud Run?

Each command becomes a Cloud Run job from the app's image, started by a Cloud Scheduler job at $0.10 a month after the first 3 per billing account. Set the time zone the server's crontab used, because Scheduler defaults to UTC, and stop the crontab on the server at the switch.

Can a Cloud Run app keep uploaded files on its disk?

No. Cloud Run's file system lives in the instance's memory and disappears with the instance. Uploads go to a Cloud Storage bucket at $0.020 per GiB a month, through the client library or a Cloud Storage FUSE mount, which has no file locking.

Can Cloud Run send email on port 25?

No. Google Cloud blocks outbound connections to port 25 by default. Send mail through a provider on port 587 or through its API, and check this before the switch, together with any partner API that allowlists the old server's IP address.

How long does Cloud Run wait for an app to shut down?

Cloud Run sends SIGTERM and kills the container 10 seconds later, where systemd waits 90 seconds by default. Handle SIGTERM by closing the server and finishing open requests, so a slow shutdown is not cut off.

Sources

We wrote this guide while building Exodus, a free tool that works with your coding agent: it audits an app on your machine, compares today's bill with Google Cloud Run at list prices, and plans the move. The CLI is open source: github.com/elim-io/exodus. A sample report: exodus.elim.io/demo. Exodus is on Product Hunt today: Exodus by elim.io.

What Cloud Run costs, with worked examples

ELIM — Wed, 14 Oct 2026 07:07:38 +0000

This guide was first published on exodus.elim.io. Prices are Google's list prices on the date in the text.

Cloud Run costs $0.000024 per vCPU-second, $0.0000025 per GiB-second and $0.40 per million requests on its default request-based billing in Tier 1 regions, after a monthly free tier of 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests per billing account. A small app at 2,000 visits a day, with a worker and Cloud SQL, costs $11.09 a month, $1.19 of it on Cloud Run.

In short

Request-based Cloud Run in Tier 1 costs $0.000024 per vCPU-second, $0.0000025 per GiB-second and $0.40 per million requests; Tier 2 regions cost 1.4 times as much.
The free tier, 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests a month, belongs to the billing account and is shared by every project on it.
A small app at 2,000 visits a day costs $11.09 a month, and Cloud SQL's db-f1-micro with 10 GiB is $9.37 of it.
One always-busy vCPU with 512 MiB costs $44.71 a month on instance-based billing; for that load a VPS usually costs less.
A minimum instance kept warm adds about $9.86 a month, and a revision scales to 100 instances unless you set a maximum.

Prices are Google's list prices in US dollars for Tier 1 regions, read on October 12, 2026.

How a line of the bill is computed

Cloud Run's bill is arithmetic. Every part of an app uses some number of vCPU-seconds, GiB-seconds, requests, hours or gigabytes in a month; each has a list price; the free tier comes off the top. Exodus prices a report the same way, with plain code and Google's published prices, so every line can be checked by hand. Every line follows one rule: take what you used, subtract what is free, and multiply by the price, never going below zero. The free part belongs to the billing account, not to the app, and resets on the first of the month. A month here is 730 hours for anything always on, and 30 days for anything counted per request.

The web service from the example below, line by line. Two of its three lines are inside the free tier.

Two details decide how much a service uses. First, request-based billing counts an instance's time while at least one request is open on it, rounded up to 100 ms, so two requests that overlap on one instance are billed once. The examples below count every request's time separately, as if none overlapped, so they are an upper bound: with concurrency, the real line is lower, never higher. Second, memory is billed for the same seconds as CPU, at the size you set, so 512 MiB is half a GiB for every billed second.

The prices

The prices below are Tier 1, the cheaper of Cloud Run's two price groups. Tier 1 holds, for example, us-central1 in Iowa, us-east1 in South Carolina, europe-west1 in Belgium, europe-west4 in the Netherlands and asia-northeast1 in Tokyo. In Tier 2 regions, such as London, Frankfurt, Zurich, Singapore and Sydney, request-based Cloud Run costs 1.4 times as much and instance-based 1.2 times; choosing a region has the whole list.

Cloud Run, request-based billing, the default, where you pay while a request is in flight, while an instance starts and while it shuts down:

CPU $0.000024 per vCPU-second, memory $0.0000025 per GiB-second, $0.40 per million requests.
Free every month, per billing account: 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests.
A minimum instance kept warm bills its idle time at $0.0000025 per vCPU-second and per GiB-second.
Requests refused by IAM, because the caller had no right to call, are not billed.

Cloud Run, instance-based billing and jobs, where you pay for every second an instance exists:

CPU $0.000018 per vCPU-second, memory $0.000002 per GiB-second, no charge per request.
Free every month: 240,000 vCPU-seconds and 450,000 GiB-seconds.
A job's instance is billed for its whole life, with a minimum of one minute.

The two free tiers are separate pools. Do not add them up: a service on request-based billing gets 180,000 vCPU-seconds, not 420,000.

Around it:

Cloud SQL for PostgreSQL db-f1-micro, a shared-core machine with 0.6 GiB of memory: $0.0105 an hour. SSD storage $0.17 per GiB a month, backups $0.08 per GiB a month of what they hold.
Cloud Tasks: the first million operations a month free, then $0.40 per million.
Cloud Scheduler: 3 jobs free per billing account, then $0.10 per job a month.
Artifact Registry, where your images live: 0.5 GiB free, then $0.10 per GiB a month.
Secret Manager: 6 active secret versions free, then $0.06 each a month; 10,000 reads free, then $0.03 per 10,000.
Cloud Build, which builds the image from source: 2,500 build-minutes a month free on its default machine, then $0.006 a minute.
Cloud Logging: the first 50 GiB of logs per project a month free, then $0.50 per GiB.
Internet egress, the bytes your responses send out, Premium tier: $0.12 per GiB after the first free GiB, up to 1 TiB a month.

You can read Cloud Run's prices the way the bill reads them, from Google's Cloud Billing Catalog. Here is the API's answer for a few of Cloud Run's SKUs, the billing codes behind each line:

Cloud Run's prices from the Billing Catalog API, effective Oct 12, 2026. Tier 2 is 1.4 times Tier 1 for request-based CPU and 1.2 times for instance-based.

The catalog needs an access token in a header file, never on the command line. Reading your first Google Cloud bill shows how the same SKUs appear on an invoice.

A web service at 2,000 visits a day

Say each visit makes 10 requests and each request takes 0.35 s of one vCPU, with 512 MiB of memory. That is a typical server-rendered app or an API behind a single-page front end.

Requests: 2,000 x 10 x 30 = 600,000 a month, inside the free 2 million: $0.00.
CPU: 600,000 x 0.35 s = 210,000 vCPU-seconds. The free tier takes 180,000, so 30,000 x $0.000024 = $0.72.
Memory: 210,000 s x 0.5 GiB = 105,000 GiB-seconds, inside the free 360,000: $0.00.

The web service costs 72 cents a month. Memory is the line people worry about and the one that matters least: at 512 MiB it is 5% of the price of a billed second.

The same service at other levels of traffic, with the same assumptions:

The web service by traffic, free tier applied, overlap not counted. Above 2,000 visits a day the CPU line grows with the traffic; requests start to bill above about 6,700 visits a day.

At 20,000 visits a day the CPU line alone is 1.92 million billable vCPU-seconds, about 533 hours of a busy vCPU. That is where it is worth looking at concurrency and the real overlap of your requests, and at the comparison below. Cloud Run costs by traffic works through more levels, with real request durations.

A worker turned into Cloud Tasks

Say the app sends 1,300 background jobs a day, each 0.5 s of CPU: emails, webhooks, a thumbnail. On a PaaS that is a worker process waiting on a Redis queue all day. On Cloud Run each job becomes an HTTP request from Cloud Tasks to a handler on the same service, as background workers with Cloud Tasks shows.

CPU: 1,300 x 30 x 0.5 s = 19,500 vCPU-seconds. The web line has used the free tier, so 19,500 x $0.000024 = $0.47.
Memory: 9,750 GiB-seconds, and with the web line's 105,000 still inside the free 360,000: $0.00.
Requests and tasks: 39,000 a month each, inside Cloud Run's free 2 million and Cloud Tasks' free million: $0.00.

On a PaaS the same worker is a second always-on process, billed every hour whether it works or waits, plus the Redis it waits on.

Postgres on Cloud SQL

The smallest shared-core instance, up all month, with 10 GiB of SSD:

730 hours x $0.0105 = $7.67
10 GiB x $0.17 = $1.70

Together $9.37 a month, plus a few cents for backups of a small database. The database is usually the largest line of a small app's bill, and it is the one line that does not scale to zero.

Three things to know about this machine. It shares a CPU and has 0.6 GiB of memory, which is enough for a small app's database and not for a busy one. Google does not cover shared-core machines with the Cloud SQL SLA. And if you stay on a Postgres major version past the end of its standard support, Google adds extended support at $0.018 an hour for db-f1-micro, more than the machine itself. The smallest Cloud SQL instances compares the next sizes up, and Cloud SQL, Firestore or serverless Postgres covers the options that cost less when the database is small or idle.

The whole app

Add the rest: three schedules in Cloud Scheduler (free), 1 GiB of images in Artifact Registry (0.5 GiB over the free tier: $0.05), five secrets (free), and 4 GiB of egress at $0.12 ($0.48).

The small app's month at 2,000 visits a day. The database is about 85% of the bill; everything on Cloud Run itself is $1.19.

Web service: $0.72
Worker as Cloud Tasks: $0.47
Cloud SQL, db-f1-micro with 10 GiB: $9.37
Cloud Scheduler, 3 jobs: $0.00
Artifact Registry, 1 GiB: $0.05
Secret Manager, 5 secrets: $0.00
Egress, 4 GiB: $0.48

Total: $11.09 a month.

The egress line is on the high side. Google's network pricing page lists $0.12 a GiB, but Cloud Run's own SKU for traffic from Europe to Europe is $0.105 in the Billing Catalog, and that is what our bills show.

The free tiers are per billing account, so this example gives all of them to one app. If you run several apps or projects in one account, they share them, and the order in which they use them up decides which project gets billed. Our own bills showed it: secrets on two of our services billed a few cents a month only because other projects on the account had already used the six free versions.

Lines that surprise a first bill

The example leaves out a few settings that are easy to switch on and bill every hour of the month, whatever the traffic:

A minimum instance. One instance of 1 vCPU and 512 MiB kept warm bills its idle time at $0.0000025 per vCPU-second and per GiB-second: 2,628,000 seconds x $0.00000375 = about $9.86 a month, as much as the database. Min instances and startup CPU boost shows when it is worth it.
High availability on Cloud SQL. A standby in a second zone doubles the machine: db-f1-micro goes from $0.0105 to $0.021 an hour.
A load balancer for a custom domain. It bills per hour and per gigabyte, apart from Cloud Run; custom domains and HTTPS compares it with Firebase Hosting.
A fixed outbound address, for a partner that allows only known IPs. It needs Cloud NAT, which bills per hour; egress on Google Cloud has the numbers.

None of them is needed for a small app on day one.

When Cloud Run costs more

Request billing rewards idle time. A process that keeps a CPU busy most of the day, such as an image resizer under constant load or a worker that never waits, has none to give. Run it on instance-based billing, one vCPU and 512 MiB, up all month:

CPU: 730 h x 3,600 s = 2,628,000 vCPU-seconds, less 240,000 free, x $0.000018 = $42.98
Memory: 1,314,000 GiB-seconds, less 450,000 free, x $0.000002 = $1.73

That is $44.71 a month for one always-busy core, and $49.93 once the free tier is used by something else. On request-based billing the same instance, busy all day, would cost $61.14; the two cross at about 18 busy hours a day, as the chart in what Cloud Run is shows. A one-year commitment takes 17% off Cloud Run's prices, which helps a steady service and not a spiky one.

For steady load around the clock, a fixed-price VM or VPS usually costs less than any Cloud Run setting, and Cloud Run or a VPS compares them. In this case Exodus's verdict is to stay, and the report says why.

What our own services cost

Exodus team: these are our own small services on Cloud Run in europe-west1, October 2026, from steady days of the billing export.

A Rust API on a document database, with a scheduled job every minute: $0.13 a month. Its Cloud Run usage, $1.79 at list prices, was all inside the free tier; the 13 cents were lines outside Cloud Run, such as a secret.
A Rust API, a web app and a worker on Cloud SQL db-f1-micro with 10 GiB: $9.79 a month, of which the database was $9.34. The estimate made from list prices, as above, was $9.64; the gap was storage reads, traffic between zones and free tiers used by other projects.
Five tiny services sharing one project: $0.69 a month.
A one-page static site behind nginx: about a cent.

The first days after a move cost more than a steady month, because the first deploys build on Google: Cloud Build charged $2.10 on the first day of one of ours.

There is no hard cap

Google bills what runs. A bug that loops, or a crawler that hammers an endpoint, scales the service up and the bill with it, to 100 instances per revision by default. Set a maximum number of instances on every service; for a small app, 3 to 10 is a sane start:

gcloud run services update my-service \
  --region europe-west1 \
  --max-instances 3

Then set a budget alert on the billing account. A spend cap budget can also pause Cloud Run in one project when its estimated cost passes an amount; it acts on estimated costs, not instantly, and anything used before it acts is billed as usual. Budget alerts and the billing export sets up both.

Where Exodus comes in

An Exodus report does this arithmetic for your app: it reads the processes, the database and the schedules from your repository, asks for your traffic, and prices each part on today's host and on Cloud Run from these list prices, line by line, with the date the prices were read. Once the app runs on Google, exodus bill reads the real month from your project's billing export in BigQuery, so the estimate can be checked against the invoice.

FAQ

Is Cloud Run free for a small app?

Cloud Run itself is free for a small app while its usage stays inside the monthly free tier of 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests per billing account; the web service in this guide costs $0 at 500 visits a day. The database does not scale to zero: Cloud SQL's smallest instance with 10 GiB is $9.37 a month.

Does Cloud Run charge when there is no traffic?

On request-based billing, the default, a Cloud Run service is billed only while a request is open on an instance, while it starts and while it shuts down. A few settings bill every hour whatever the traffic: a minimum instance, about $9.86 a month at 1 vCPU and 512 MiB, high availability on Cloud SQL, a load balancer and Cloud NAT.

Is Cloud Run cheaper than a VPS?

Cloud Run costs less than a VPS for an app that is idle most of the day, because request billing rewards idle time. For steady load around the clock, a fixed-price VM or VPS usually costs less: one always-busy vCPU with 512 MiB costs $44.71 a month on instance-based billing and $61.14 on request-based.

How much does a Cloud Run job cost?

A Cloud Run job is billed at instance-based prices, $0.000018 per vCPU-second and $0.000002 per GiB-second in Tier 1, for the whole life of its instance, with a minimum of one minute. Jobs draw on the instance-based free tier of 240,000 vCPU-seconds and 450,000 GiB-seconds a month.

Can I set a spending limit on Cloud Run?

Google bills what runs, so there is no hard cap. Set a maximum number of instances on every service, 3 to 10 for a small app instead of the default 100 per revision, and a budget alert on the billing account. A spend cap budget can pause Cloud Run in one project, but it acts on estimated costs, not instantly.

Sources

The patterns that break on Cloud Run, and their replacements

ELIM — Wed, 14 Oct 2026 07:07:02 +0000

This guide was first published on exodus.elim.io. Prices are Google's list prices on the date in the text.

Six patterns break on Cloud Run: a worker waiting on a queue, work after the response, timers inside the app, files on local disk, sessions in memory and long-lived connections. Each assumes a process that runs on its own, owns a disk and keeps its memory. Their replacements are Cloud Tasks, Cloud Scheduler, Cloud Storage, signed cookies, and sockets that reconnect.

In short

With request-based billing, an instance has CPU only while a request is open, and an idle one is stopped within 15 minutes with SIGTERM and 10 seconds.
After the free tiers, a queue worker kept on at 1 vCPU and 512 MiB costs $44.71 a month, a worker pool $25.95, and 100,000 Cloud Tasks jobs of 0.5 s fit in the free tier.
Cloud Scheduler gives 3 jobs free per billing account, then $0.10 per job per 31 days, and each job's time zone defaults to UTC.
Cloud Storage Standard costs $0.02 per GiB a month in europe-west1, and a signed upload URL is valid for at most 7 days.
exodus 0.1.3 found 5 of the 6 patterns in our sample app; work after the response needs a look by hand.

Prices are Google's Tier 1 list prices, read on October 12, 2026.

The one fact behind all six

Most apps that run on a platform such as Heroku, Railway or Render run on Cloud Run with a handful of changes, and every item in that handful comes from one fact about how Cloud Run runs a service. A product planned for Cloud Run from the first commit never picks them up. A Cloud Run service runs your container on instances. Each instance takes requests, and with request-based billing Cloud Run allocates its CPU only while at least one request is in flight. Between requests the instance still exists, with its memory, but its CPU is taken away, so any code that runs on its own, a loop, a timer, a promise still resolving after the response, makes no progress. After a quiet spell Cloud Run keeps an idle instance for up to 15 minutes and then shuts it down, sending SIGTERM and allowing 10 seconds before the process is killed. When traffic grows it starts more instances, and a request can land on any of them.

One instance of a request-based service: CPU only inside requests, so work left over after the response stalls; an idle instance is stopped within 15 minutes.

The filesystem adds the last piece. A Cloud Run instance's disk lives in its memory: files written there count against the memory limit, are invisible to other instances and vanish when the instance stops.

Instance-based billing changes the first part, because the instance keeps its CPU for its whole life, but it does not keep one instance alive forever and it does not give you a disk. It also bills every second the instance exists, which turns some of these patterns from broken into expensive.

Finding them in your code

The Exodus CLI looks for all six. We wrote a small Express app that has every one of them, a BullMQ worker, a receipt sent after the response, a node-cron timer, Multer writing uploads to a folder, express-session's default memory store and a WebSocket server, and ran exodus check on it.

exodus 0.1.3 on the sample app found five of the six patterns with their file and line; the receipt sent after the response was not flagged, so check for that one by hand.

It found five, each with its file and line. It did not flag the sixth, an await sendReceipt() after res.json(), so that one needs a look by hand. A rough search covers the common forms:

grep -rnE "bullmq|sidekiq|celery|rq worker|node-cron|setInterval|apscheduler|whenever" \
  --include='*.js' \
  --include='*.ts' \
  --include='*.py' \
  --include='*.rb' \
  . | grep -v node_modules
grep -rnE "multer|diskStorage|writeFile|:local|FileSystemStorage|sqlite" \
  --include='*.js' \
  --include='*.ts' \
  --include='*.py' \
  --include='*.rb' \
  --include='*.yml' \
  . | grep -v node_modules
grep -rnE "MemoryStore|express-session|WebSocketServer|socket.io|EventSource" \
  --include='*.js' \
  --include='*.ts' \
  . | grep -v node_modules

A Procfile, railway.json or render.yaml with more than one process is a second hint: anything that is not the web process is probably a worker or a clock.

1. A worker waiting on a queue

What it looks like: a BullMQ, Sidekiq, Celery or RQ worker, often its own process in a Procfile or its own service, pulling jobs from Redis.

Why it breaks: the worker is a loop that waits for the next job. On a request-based service it gets no CPU between requests, so jobs stall. On instance-based billing it runs, but bills every second whether there is work or not, and it still has no request to keep Cloud Run from scaling it down.

The replacement: Cloud Tasks. Each job becomes an HTTP request to your own service. Where the code pushed a job to Redis, it creates a task, and Cloud Tasks calls a handler with the job's body:

await client.createTask({
  parent: client.queuePath(PROJECT, 'europe-west1', 'emails'),
  task: {
    httpRequest: {
      httpMethod: 'POST',
      url: `${BASE}/tasks/send-email`,
      headers: { 'Content-Type': 'application/json' },
      body: Buffer.from(JSON.stringify({ to })).toString('base64'),
      oidcToken: { serviceAccountEmail: INVOKER, audience: BASE },
    },
  },
})

The handler at /tasks/send-email does the job and answers with a 2xx status, which deletes the task. Any other answer, or no answer in time, is retried with backoff. The handler has a dispatch deadline of up to 30 minutes, so longer jobs belong in a Cloud Run job. Two rules keep it safe: check the OIDC token, so only the queue can call the handler, and make the handler safe to run twice, because Cloud Tasks delivers at least once and in rare cases runs a task more than once.

A worker becomes a handler: the service creates a task, Cloud Tasks calls the same service with an OIDC token, and the queue keeps the retries, the rate and the backoff.

The limits: a task's body is at most 1 MiB, a task waits in its queue for at most 31 days, and a queue dispatches up to 500 tasks a second. The first million Cloud Tasks operations a month are free, then $0.40 per million.

What waiting costs. Kept as it is, a worker on a service with instance-based billing, 1 vCPU and 512 MiB, costs $44.71 a month after the free tier, whether it handles one job or a million. A worker pool, Cloud Run's resource for processes that pull work, bills $0.000011244 per vCPU-second and comes to $25.95 for the same instance at its default price. The same work as Cloud Tasks, say 100,000 jobs of half a second each, is $1.30 at list price and fits in the free tier if nothing else uses it.

What a waiting worker costs a month after the free tiers: $44.71 kept always on, $25.95 as a worker pool, nothing as 100,000 Cloud Tasks jobs of 0.5 s.

Google's own worker pool example gives $11.61 for one instance of the same size for a month. That figure matches the pool's three-year committed price, $0.000006072 per vCPU-second, less the free tier valued at the default price; at the default price, which is what you pay without a commitment, it is the $25.95 above.

When to keep a loop: a consumer of a stream, a job that holds one connection for hours, or a pull subscription that cannot become a push. Worker pools are generally available since April 14, 2026, run without an endpoint and do not scale on their own: you set the number of instances. Use them for that exception, not for an ordinary job queue. The Cloud Tasks guide has the queue, the IAM roles, the handler and the retries in full.

2. Work after the response

What it looks like: res.send() followed by await sendEmail(), a promise nobody awaits, a "fire and forget" call to an analytics API, a goroutine started by a handler that has already returned, FastAPI's BackgroundTasks.

Why it breaks: once the response is sent, the request is over, and on a request-based service the CPU goes with it. The leftover work stalls until the next request happens to wake the instance, and if the instance is shut down first, it never finishes. Nothing fails loudly: the email arrives an hour late, or not at all.

The replacement: finish the work before you answer, if it is short, or hand it to Cloud Tasks as above and answer at once. For a receipt email, a task is the better choice: the user gets the response without waiting, and the queue retries the email if the mail API is down.

This is the one pattern the CLI did not flag in our sample, and the one most often missed in review, because the code looks correct and works on a server. Read every handler for code after the line that sends the response. The work after the response guide shows the forms it takes in Node, Python, Ruby and Go.

3. Timers and cron inside the app

What it looks like: node-cron, setInterval, APScheduler, Celery beat, whenever, or a separate "clock" process.

Why it breaks: a service scaled to zero has no process to run the timer, and a running one gets no CPU between requests. With several instances, the timer fires once per instance, so a daily email goes out three times on a busy day and zero times on a quiet one.

The replacement: Cloud Scheduler. It sends an HTTP request on a cron schedule. For short work it calls an endpoint of the service, POST /cron/daily-digest, with an OIDC token. For long work it starts a Cloud Run job, the same image with another command, which runs for 10 minutes by default and up to 168 hours (7 days).

gcloud scheduler jobs create http daily-digest \
  --location=europe-west1 \
  --schedule="0 7 * * *" \
  --time-zone="Europe/Berlin" \
  --uri="$SERVICE/cron/daily-digest" \
  --http-method=POST \
  --oidc-service-account-email="$SA"

Three details bite. The time zone: each Scheduler job has its own, and it defaults to UTC, while node-cron used the server's. Overlap: if a run is still going when the next fires, both run, so long work needs a lock or a job. Retries: a Scheduler job does not retry a failed attempt unless you set a retry count, and an HTTP attempt has a deadline between 15 seconds and 30 minutes. Each billing account gets three Scheduler jobs free, then $0.10 per job per 31 days. The Cloud Scheduler guide covers jobs, retries and locks.

4. Files on local disk

What it looks like: Multer's dest, Active Storage's :local service, Django's FileSystemStorage, fs.writeFile into a data/ folder, SQLite on disk, logs written to a file.

Why it breaks: the filesystem of a Cloud Run instance lives in its memory. A file counts against the memory limit, so a few large uploads can crash the instance; it is invisible to the other instances, so an upload saved on one is a 404 on the next; and it disappears when the instance stops.

The replacement: a Cloud Storage bucket. For uploads, let the browser send the file straight to the bucket with a signed URL, so the bytes never pass through your service and never touch its memory:

const [url] = await bucket.file(`uploads/${id}`).getSignedUrl({
  version: 'v4',
  action: 'write',
  expires: Date.now() + 15 * 60 * 1000,
  contentType: type,
})

The service signs a PUT URL for one object, valid for 15 minutes here and for at most 7 days, the browser puts the file there, and the service stores only the key. A file the app generates goes to the bucket through the client library in the same way.

Uploads with a signed URL: the service signs, the browser sends the bytes straight to the bucket, and the service keeps only the object's key.

A temporary file inside one request, for a resize or an unzip, can stay in /tmp as long as it fits in memory and is deleted before the response. Logs go to stdout, where Cloud Logging collects them. Standard storage costs $0.02 per GiB a month in europe-west1, so 5 GiB of uploads cost about $0.10.

SQLite is the hard case, because it needs a real disk that one process owns. Move the data to Postgres before the move. The Cloud Storage guide has the bucket, the CORS rule and the download side.

5. Sessions and caches in memory

What it looks like: express-session's default MemoryStore, Flask-Session's filesystem backend, an in-process cache of logged-in users, or a Redis that holds only sessions.

Why it breaks: the next request can land on another instance, which has never seen the session, and scaling to zero drops them all, so people are logged out at random. Session affinity, which Cloud Run offers as an option, is best effort: it is broken as soon as the instance stops or is full, so it cannot hold a login. Keeping a Redis only for sessions works, but bills all month for a few kilobytes.

The replacement: signed cookies. cookie-session in Express, the default cookie store in Rails, signed cookies in Django. Sign them with a key from Secret Manager, keep them small (browsers guarantee at least 4,096 bytes per cookie, enough for a user id, a role and an expiry), and set Secure, HttpOnly and SameSite=Lax. If you need "log out everywhere", keep a session version on the user's row and check it on each request; when the cookie is not enough, a sessions table in the database the app already has does the job.

An in-process cache is fine as long as the app works without it: each instance warms its own, and a new instance starts cold. The sessions guide covers both options.

6. Long-lived connections

What it looks like: WebSockets, server-sent events, a long poll.

Why it is a problem: Cloud Run supports WebSockets, but a socket is a request and lasts no longer than the request timeout, 5 minutes by default and 60 minutes at most, so clients must reconnect. An instance with any open WebSocket is billed as instance-based for as long as the socket is open; one instance held open all month at 1 vCPU and 512 MiB is the $44.71 from the chart above. Messages between users connected to different instances need a shared store or a pub/sub, because there is no single process that sees everyone.

The replacement: for a few sockets, keep them, raise the timeout and let clients reconnect. For a chat or a live dashboard with thousands of connections open all day, a managed realtime service, or staying on an always-on host, usually costs less. The WebSockets and SSE guide works out where the line is.

The small ones

A few smaller habits do not break the app outright but make the first deploy fail. The server must listen on the port in $PORT, 8080 by default, on 0.0.0.0. Logs go to stdout and stderr, not a file. The process must handle SIGTERM and finish its requests within 10 seconds. Secrets come from Secret Manager, not a .env file baked into the image. The stack guide shows each of these for Node, Python, Rails and Go.

A checklist before the move

Every process other than the web process has a destination: Cloud Tasks, Cloud Scheduler, a job or a worker pool.
No handler does work after it sends the response.
Every timer is a Scheduler job with its time zone set and an endpoint or job that tolerates overlap.
Nothing is written to the local disk except temporary files inside one request.
Sessions live in signed cookies or the database; the app works if any instance disappears.
Long-lived connections reconnect, and their cost has been worked out.
Each change is deployed and tested on the current host first, before anything moves.

The last point matters most. Every replacement here, a Cloud Tasks queue, a bucket, a Scheduler job, a signed cookie, works from an app still running on Heroku, Railway or Render. Making the changes there means the move itself only changes where the container runs; the rest of it is in Moving from Heroku and Moving from Railway or Render.

Where Exodus comes in

exodus audit lists every place these patterns occur, with the file and line, and the report turns each one into a task in the plan, in the order to do them. exodus check runs the same rules in CI and fails the build when a new one appears. As our sample showed, it does not catch every case of work after the response, so read your handlers for that one.

FAQ

Can a Cloud Run service keep working after it sends the response?

Not on request-based billing, the default: the CPU goes with the request, so the leftover work stalls and is lost if the instance stops first. Finish short work before answering, or hand it to Cloud Tasks and answer at once. Instance-based billing keeps the CPU but bills every second the instance exists.

Can I use node-cron or setInterval on Cloud Run?

No. A service scaled to zero has no process to run the timer, and with several instances it fires once per instance. Cloud Scheduler sends an HTTP request on a cron schedule instead; each billing account gets three jobs free, then $0.10 per job per 31 days.

Can a Cloud Run service write files to disk?

Only temporary ones. The filesystem lives in the instance's memory, counts against the memory limit, is invisible to other instances and vanishes when the instance stops. A temporary file inside one request is fine; uploads and generated files go to a Cloud Storage bucket, $0.02 per GiB a month in europe-west1.

Does session affinity keep users logged in on Cloud Run?

No. Session affinity is best effort and breaks as soon as the instance stops or is full, and scaling to zero drops every in-memory session. Keep sessions in signed cookies, which browsers support up to at least 4,096 bytes, or in a table of the database the app already has.

Do WebSockets work on Cloud Run?

Yes, but a socket is a request and lasts no longer than the request timeout, 5 minutes by default and 60 at most, so clients must reconnect. An instance with an open socket is billed as instance-based, $44.71 a month at 1 vCPU and 512 MiB if held open all month.

Sources

Exodus: move an app to Google Cloud Run with the coding agent you already use

ELIM — Wed, 14 Oct 2026 07:06:57 +0000

Exodus is on Product Hunt today: Exodus by elim.io.

Exodus is a free web cabinet and an open-source CLI. Together with the coding agent you already use, such as Claude Code, Codex, Cursor or Gemini CLI, it audits an app on your machine. It shows what the app costs today and on Google Cloud Run, lists every change the move needs with its file and line, and gives the agent a plan to work through. It can also design a new product for Cloud Run from an idea.

Why we built it

Cloud Run suits most web apps: it scales to zero, bills only for the time your code runs, and includes 2 million requests a month in its free tier. Moving an app there from a platform such as Heroku, Railway or Render is rarely about the container. It is about four habits a platform with long-running processes lets you keep and Cloud Run does not.

Timers inside the process. An instance has CPU only while it answers a request, and there may be several instances, so a cron in your server fires late, twice or never. Each schedule moves to Cloud Scheduler: short work calls an endpoint, long work starts a Cloud Run job.
A worker waiting on a queue. For the same reason the jobs stall between requests. Each job becomes an HTTP task in Cloud Tasks that posts to a handler, and the queue keeps the retries and the rate limits.
Files on local disk. The disk lives in the instance's memory and disappears when the instance stops; other instances never see it. Uploads go to a Cloud Storage bucket through a signed URL, and the app keeps only the key.
Sessions in memory. The next request lands on another instance and the user is signed out. The session goes into a signed cookie or a table of the database the app already has.

We met all four while moving our own apps and wrote 59 guides about them along the way. Exodus is those guides turned into a tool.

How it works

Sign up at app.exodus.elim.io and install the CLI once: curl -fsSL exodus.elim.io/install | sh
Give your agent the one line from the cabinet. It runs exodus init and exodus audit in your repository, answers the questions it can from the code and asks you the rest.
exodus send uploads the findings and the answers, and the cabinet builds the report: today's bill against Cloud Run at Google's list prices, the changes, and a plan. Exodus never receives your source code.
The agent works through the plan task by task, and each new send updates the report.

A sample report

exodus.elim.io/demo opens the report of a sample project, lumen-api: a Rust API with a worker, timers and uploads on Railway, $48.00 a month today against $10.83 on Cloud Run after 4 changes, with 4 of 9 plan tasks done.

DEV Community: ELIM

Moving from a VPS to Cloud Run: what each piece becomes

In short

When moving pays, and when it does not

What the server does for you

Step 1: the app in a container

Step 2: files on disk

Step 3: the database

Step 4: secrets and settings

Step 5: deploy

Step 6: cron, timers and the processes next to the app

Step 7: nginx, the network and the switch

What breaks most often

Where Exodus comes in

FAQ

Is Cloud Run cheaper than a VPS?

How do I move cron jobs from a VPS to Cloud Run?

Can a Cloud Run app keep uploaded files on its disk?

Can Cloud Run send email on port 25?

How long does Cloud Run wait for an app to shut down?

Sources

What Cloud Run costs, with worked examples

In short

How a line of the bill is computed

The prices

A web service at 2,000 visits a day

A worker turned into Cloud Tasks

Postgres on Cloud SQL

The whole app

Lines that surprise a first bill

When Cloud Run costs more

What our own services cost

There is no hard cap

Where Exodus comes in

FAQ

Is Cloud Run free for a small app?

Does Cloud Run charge when there is no traffic?

Is Cloud Run cheaper than a VPS?

How much does a Cloud Run job cost?

Can I set a spending limit on Cloud Run?

Sources

The patterns that break on Cloud Run, and their replacements

In short

The one fact behind all six

Finding them in your code

1. A worker waiting on a queue

2. Work after the response

3. Timers and cron inside the app

4. Files on local disk

5. Sessions and caches in memory

6. Long-lived connections

The small ones

A checklist before the move

Where Exodus comes in

FAQ

Can a Cloud Run service keep working after it sends the response?

Can I use node-cron or setInterval on Cloud Run?

Can a Cloud Run service write files to disk?

Does session affinity keep users logged in on Cloud Run?

Do WebSockets work on Cloud Run?

Sources

Exodus: move an app to Google Cloud Run with the coding agent you already use

Why we built it

How it works

A sample report

Links