DEV Community: Abhishek Jaiswal

Where to host Uptime Kuma in 2026: five options, priced

Abhishek Jaiswal — Tue, 03 Nov 2026 10:23:39 +0000

Uptime Kuma runs well anywhere that gives it an always-on container and a disk that survives a restart. In 2026 the practical choices are Ownkube (about $5 a month, one click), Fly.io (from about $2.34), Railway (from the $5 Hobby fee), Render (from $7.25) and a VPS you run yourself.

Heroku and Replit are out: Uptime Kuma's own README lists them as unsupported, because their filesystems don't keep the data file.

Wherever you run it, keep it off the platform your apps run on, since a monitor that goes down with your apps can't tell you they are down.

Our picks

If you want	Pick
One click, HTTPS and a persistent volume set up for you, on a prepaid bill	Ownkube
The lowest line item and you are fine writing a `fly.toml`	Fly.io
A template deploy on a platform you already use	Railway
A flat price and you already run services on Render	Render
Full control, and you already patch a server	Your own VPS
No server at all	A hosted monitor such as UptimeRobot

What Uptime Kuma needs from a host

Uptime Kuma is a single Node.js process. It stores monitors, check history and settings in a SQLite file, so the host needs four things:

A disk that survives restarts and redeploys. Uptime Kuma's README warns that network file systems such as NFS are not supported, so use a local or block volume.
A process that never sleeps. Free tiers that spin down on idle stop your monitors without telling you.
One instance. SQLite allows one writer, so you run one copy, not a scaled group.
A public hostname with HTTPS, for the dashboard and for status pages your users will open.

The options at a glance

Prices are approximate list prices from each provider's pricing page, as of November 2026, for one small instance with a 1 to 2 GB volume.

Host	Monthly cost	Disk	Setup	Who patches the server
Ownkube	About $5, metered per minute	2 GiB volume, no storage charge	One click from the Marketplace	Ownkube
Fly.io	About $2.34 (256 MB Machine plus 1 GB volume)	Fly Volume, $0.15 per GB	`fly launch` and a `fly.toml`	Fly.io
Railway	$5 Hobby fee, which includes $5 of usage	Volume, about $0.15 per GB	Template	Railway
Render	$7.25 (Starter instance plus 1 GB disk)	Persistent disk, $0.25 per GB	Docker image service	Render
Your own VPS	The server, plus your time	Local disk	Docker Compose	You

The options, one by one

Ownkube

Uptime Kuma is in the Ownkube Marketplace. One deploy creates the app from the official image, mounts a 2 GiB persistent volume for the SQLite file, and gives it an *.ownkube.app hostname with automatic HTTPS. There is no Postgres to pay for, since Uptime Kuma doesn't use one.

It costs about $5 a month: CPU and memory billed per minute, and the volume carries no storage charge. It runs in Mumbai or Germany. You can add your own domain for the status page.

Finish setup right after deploy, since the first person to open the dashboard creates the admin account. And leave sleep off: a sleeping app runs no checks, so your monitors would stop until someone opened the dashboard.

Billing is a prepaid wallet. Pay as you go starts with a $5 top-up, and unused credit never expires. See the Uptime Kuma template, or deploy it now.

Fly.io

Fly.io has the cheapest line here. A shared-cpu-1x Machine with 256 MB is $2.19 a month running all month, and a 1 GB volume adds $0.15. You write a fly.toml that mounts the volume at /app/data, then run fly deploy.

A large set of monitors needs more memory than 256 MB, which moves the line up. Volumes bill on provisioned size even while the Machine is stopped. Fly.io also runs in many regions, which helps with the placement question below. See Fly.io pricing explained.

Railway

Railway has Uptime Kuma templates that attach a volume for you. The Hobby plan is $5 a month and includes $5 of usage. Memory bills at about $10 per GB a month, CPU at about $20 per vCPU a month, and volumes at about $0.15 per GB.

A small instance can fit inside the included usage. A heavier one pushes past it, so check the usage page after the first week. See Railway pricing explained.

Render

Render can run the official Docker image with a persistent disk. Disks need a paid instance, so the floor is a $7 Starter instance plus $0.25 per GB of disk.

Render's docs note two catches. A service with a disk loses zero-downtime deploys, so each deploy briefly takes the monitor offline. It also can't scale past one instance, which doesn't matter for SQLite. See Render pricing explained.

Your own VPS

Uptime Kuma's own install guide is Docker Compose on a server, and it is the most common setup. You get full control and the lowest unit cost if you already run a box.

You also own everything else: OS updates, the reverse proxy and certificates, firewall rules, disk backups, and noticing when the server itself has died, which a monitor running on that server can't do.

Put the monitor somewhere else

If Uptime Kuma runs on the same platform, region or server as the apps it checks, an outage there takes the monitor down too. Your status page goes dark while users are looking for it, and no alert goes out.

That holds for Ownkube as much as anyone. If your apps run on Ownkube in Germany, put Uptime Kuma on a different provider, or at least in Mumbai. If your apps run on Render or Fly.io, Ownkube is a reasonable separate home for the monitor.

The same logic applies to alerts. Send them somewhere that doesn't depend on the monitored apps, such as email, Slack, Discord or Telegram, all of which Uptime Kuma supports.

When not to self-host Uptime Kuma

If you only need a handful of HTTP checks and don't care about owning the data, a hosted monitor is less work. UptimeRobot's free plan covers 50 monitors at a 5-minute interval, with commercial use allowed. Its cheapest paid plan, Solo, checks every 60 seconds for $9 a month billed yearly.

Self-hosting wins when you want 20-second checks without a per-monitor price, private TCP or keyword checks, branded status pages, or simply to keep the history yourself.

A quick checklist before you choose

Confirm the data directory sits on a volume that survives a redeploy.
Turn off any idle sleep or spin-down.
Run one instance only.
Put the monitor on a different provider or region from your apps.
Decide how you will back up the data file.
Send a test alert to every channel before you rely on it.

FAQ

Can I run Uptime Kuma on Heroku?

No. Uptime Kuma's README lists Heroku as unsupported. Heroku's filesystem is reset on every restart, so the SQLite file and all your monitors would be lost.

Can Uptime Kuma run on a free tier?

Not reliably. Free tiers that sleep stop the checks, and the ones that don't sleep usually have no persistent disk. Plan on a small paid instance with a volume.

How much memory does Uptime Kuma need?

Memory grows with the number of monitors and how often they check. Start small, watch the memory chart for the first week, and size up if it climbs.

What does Uptime Kuma cost on Ownkube?

About $5 a month: its CPU and memory billed per minute, with the 2 GiB volume included at no storage charge. Pay as you go starts with a $5 top-up.

Where Ownkube fits

Ownkube is a good home for Uptime Kuma when you want it running in one click with HTTPS and a persistent volume, and you are not watching apps on Ownkube in the same region. It runs alongside the rest of the Marketplace, and the same wallet pays for your apps and databases too. Deploy my first app.

Hosting that redeploys on every GitHub push: five low-maintenance options in 2026

Abhishek Jaiswal — Tue, 03 Nov 2026 10:23:38 +0000

Ownkube, Render, Railway and Heroku all rebuild and redeploy your app on every push to a GitHub branch with no pipeline to write. Fly.io gets you there through a GitHub Actions workflow you keep yourself.

What keeps maintenance low is everything around the push: whether a bad build stops itself, whether you hear about errors before users do, and whether the database backs itself up. We compare the five on those, then price a small backend (an API, a worker, an hourly job and Postgres) on three of them.

Our picks

If you want	Pick
Push to deploy for the whole backend, with logs, metrics and alerts included and a prepaid bill	Ownkube
Fixed instance prices and deploys that wait for CI to pass	Render
The fastest setup and a preview environment for every pull request	Railway
Review apps and the add-on marketplace	Heroku
Apps close to users on several continents, and you don't mind owning a workflow file	Fly.io

The five at a glance

Prices are approximate list prices from each provider's pricing page, as of November 2026.

Platform	Deploys on push	Waits for CI	Per-PR previews	Workers and cron	Postgres from
Ownkube	Yes, GitHub and GitLab	No, deploy from a branch CI merges into	No	Yes, both built in	$4 a month plus $0.25 per GB
Render	Yes	Yes	Yes	Yes, both built in	$6 a month
Railway	Yes	Yes	Yes	Yes, cron per service	Metered
Heroku	Yes	Yes	Yes, review apps	Worker dynos, Scheduler add-on	$5 a month (1 GB)
Fly.io	Through a GitHub Actions workflow	Your workflow decides	Through a GitHub Action	Process groups, scheduled Machines	About $38 a month managed

What low maintenance actually takes

Redeploying on push handles one chore. These are the others that come back every week if the platform skips them.

Builds without a Dockerfile

If every repo needs a hand-written Dockerfile, you maintain base images and build steps across all of them. Ownkube, Render, Railway and Heroku all build common Node, Python, Go and Ruby apps without one. On Ownkube that is the automatic build, and it switches to your Dockerfile when the repo has one.

Rollouts that stop a bad build

On Ownkube, health checks gate every rollout: new containers have to pass before the old ones stop, so a build that crashes on boot leaves the last good version serving. If a bad change does ship, rollback goes to any of the last 3 builds on Pay as you go and the last 10 on a plan.

Logs, metrics and alerts

Logs and CPU and memory charts come with every Ownkube app, and public web apps add request rates and p95 latency, all kept 7 days on Pay as you go, 30 on Personal and 90 on Team. Alert rules on CPU, memory or restarts email the organization owner when they fire and again when they clear. On Heroku the same visibility usually means one or two paid add-ons.

Database backups

A redeploy brings code back from Git, but not data. Managed Postgres on Ownkube takes 7-day backups with point-in-time restore on Personal and Team, turned on per database. Pay as you go databases have no backups, so that is the line to upgrade for before real users arrive.

The options, one by one

Ownkube

Ownkube is a cloud for personal software. You connect a GitHub or GitLab repo, pick a branch, and every push builds and deploys to an *.ownkube.app hostname with TLS.

Web apps, workers, scheduled jobs, Postgres and a Valkey cache sit side by side in one environment, and they reach each other by private name. Billing is a prepaid wallet: apps meter CPU and memory per minute (about $18 per vCPU and $6 per GiB a month), or sit on a flat Spark box from $5.

Ownkube doesn't wait for CI checks, has no per-PR previews, and runs in two regions, Mumbai and Germany. The preview environments guide covers what a per-branch setup looks like today.

Render

Render's auto-deploy can run on every commit or only after CI checks pass, which is the cleanest CI gate of the five. Instances are flat-priced from $7 a month, so the bill is predictable and an idle service costs the same as a busy one. See Render alternatives.

Railway

Railway has the fastest first deploy, can wait for GitHub checks, and spins up an environment per pull request. It meters usage per second, which suits many small services. See Railway pricing explained.

Heroku

Heroku's GitHub integration deploys on push, can wait for CI, and builds review apps for pull requests. Workers are dynos at the same price as web dynos, and cron runs through the Scheduler add-on. See Heroku alternatives for the dyno math.

Fly.io

Fly.io deploys with fly deploy. Deploy-on-push means a GitHub Actions workflow and an API token you manage, which gives you full control over the pipeline and one more file to maintain. It is the pick when apps need to run close to users on several continents. See Fly.io alternatives.

A small backend, priced

The stack is an API, a queue worker, a job that runs 5 minutes every hour, and a Postgres with about 5 GB of data. The Ownkube lines assume the API averages 0.1 vCPU and holds 512 MiB, the worker 0.1 vCPU and 256 MiB, since metered CPU follows actual use.

Line	Ownkube	Render	Heroku
API	Metered, about $5	Starter, $7	Basic dyno, $7
Worker	Metered, about $3	Starter, $7	Basic dyno, $7
Hourly job	Metered, under $1	Cron job, billed per run	Scheduler, one-off dyno per run
Postgres	DB 0.5 box $4 plus 5 GB, $5.25	256 MB plus 5 GB, $7.50	Essential-1 (10 GB), $9
Total	about $14, plus bandwidth	about $22, plus cron runs	about $23, plus Scheduler runs

Render and Heroku figures are approximate, as of November 2026, on Render's Hobby workspace. The database sizes are not identical: Ownkube's DB 0.5 has 0.5 GiB of memory against Render's 256 MB. A busier API moves the Ownkube line up, and a Spark box fixes it at a flat price if you prefer. Try your own sizes on the cost calculator.

Setting it up on Ownkube

Create a web app from the dashboard, connect your GitHub or GitLab account when it asks, and pick the repository and branch. Set a root directory if the app lives in a monorepo folder such as apps/api.

Add a Postgres database in the same environment and link it to the app, which hands the app its connection string as a secret variable (okctl deploy link does the same from the terminal). Add a /health route so rollouts can tell when the app is ready.

From then on every push to the branch builds and deploys. To pause deploys during an incident, run okctl deploy auto-deploy <id> --enabled=false. To have CI gate deploys, point the deployment at a release branch that your CI merges into once tests pass.

When not to pick Ownkube

Pick Railway, Render or Heroku if every pull request needs its own live preview without setup. Pick Render if deploys must wait for GitHub checks natively. Pick Fly.io if your users are far from both Mumbai and Germany.

A quick checklist before you choose

Push a commit that crashes on boot and confirm the old version keeps serving.
Roll back once, on purpose, before you need to.
Find where logs and metrics live, and how long they are kept.
Turn on database backups and test a restore.
Price the worker and the cron job, not only the web app.

FAQ

Which hosting platforms redeploy automatically from GitHub?

Ownkube, Render, Railway, Heroku, DigitalOcean App Platform, Vercel and Netlify all redeploy on push from a connected GitHub repo. Fly.io does it through a GitHub Actions workflow. Ownkube also redeploys from GitLab.

Can I stop a push from deploying on Ownkube?

Yes. Turn auto-deploy off for the app with okctl deploy auto-deploy <id> --enabled=false, and turn it back on when you are ready. Pushes made while it is off don't deploy.

What is the cheapest way to host a backend with a worker and a small database?

On metered pricing, a mostly idle API and worker cost a few dollars each, so the database is usually the biggest line. In our example the whole backend comes to about $14 a month on Ownkube. See managed Postgres pricing for the database line across eight providers.

Where Ownkube fits

Ownkube suits a small team that wants builds, rollouts, rollbacks, logs, alerts and Postgres backups to come with the app, paid from a wallet where unused credit never expires. If an app later has to run in your own or a customer's AWS account, it moves there with no rewrite, and its logs and metrics come with it. Deploy my first app.

How to deploy a Ruby on Rails app on Ownkube

Abhishek Jaiswal — Sun, 01 Nov 2026 15:37:45 +0000

A Rails app needs three things from a host: a place to run Puma, a Postgres database it can reach, and a way to run db:migrate before traffic hits the new code. Ownkube covers all three without a cloud account or hand-written YAML.

This walks through deploying a standard Rails app on Ownkube Compute: configuring Puma, wiring up a managed Postgres, setting RAILS_MASTER_KEY and SECRET_KEY_BASE, precompiling assets, and running migrations as a job.

TL;DR

Push a Rails app with a Dockerfile, and Ownkube builds and deploys it behind automatic TLS.
Add an Ownkube-managed Postgres database and set DATABASE_URL from its connection string.
Set RAILS_MASTER_KEY (or SECRET_KEY_BASE) and RAILS_ENV=production as environment variables in the dashboard, not in the repo.
Precompile assets in the Docker build step, and run db:migrate as a one-off job, so it runs once per release instead of on every container start.
Metered billing fits Rails well: Puma sits mostly idle between requests, so the CPU line barely moves outside real traffic.

1. Prepare the app for production

Rails is opinionated enough that most of the setup is standard Rails. Confirm the basics before you deploy:

config/database.yml reads its production connection from ENV["DATABASE_URL"], which is the Rails default.
config/environments/production.rb has config.assets.compile = false and config.public_file_server.enabled set to match your asset pipeline (Propshaft or Sprockets, either works).
Gemfile includes pg for the Postgres adapter and puma as the app server.

# config/database.yml
production:
  <<: *default
  url: <%= ENV["DATABASE_URL"] %>

2. Write a Dockerfile

Ownkube deploys from a Dockerfile. A multi-stage build keeps the final image small and lets you precompile assets during the build:

FROM ruby:3.3-slim AS build

RUN apt-get update -qq && apt-get install -y build-essential libpq-dev git curl \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

COPY Gemfile Gemfile.lock ./
RUN bundle config set without 'development test' \
    && bundle install --jobs 4 --retry 3

COPY . .

# Precompile assets. SECRET_KEY_BASE_DUMMY lets this run without real secrets at build time.
RUN SECRET_KEY_BASE_DUMMY=1 bundle exec rails assets:precompile

FROM ruby:3.3-slim

RUN apt-get update -qq && apt-get install -y libpq-dev curl \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY --from=build /usr/local/bundle /usr/local/bundle
COPY --from=build /app /app

ENV RAILS_ENV=production
ENV RAILS_LOG_TO_STDOUT=true
ENV RAILS_SERVE_STATIC_FILES=true

EXPOSE 3000
CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]

Puma's default config/puma.rb reads the port and worker count from environment variables already, so leave it as Rails generated it:

# config/puma.rb
port ENV.fetch("PORT", 3000)
workers ENV.fetch("WEB_CONCURRENCY", 2)
threads_count = ENV.fetch("RAILS_MAX_THREADS", 5).to_i
threads threads_count, threads_count

3. Push the repo and create the app

Connect the repository from the Ownkube dashboard (app.ownkube.io) to deploy on every push, or deploy the current directory with the okctl CLI:

okctl login
okctl up --name rails-app --port 3000

Ownkube builds the image from your Dockerfile, allocates a hostname on *.ownkube.app, and issues TLS automatically, so you have a working HTTPS URL the moment it deploys. On Personal and Team you can also serve it from a domain you own. See Custom domains.

4. Add a managed Postgres database

Create a database box from the dashboard: New > Database > Postgres. It provisions a private (in-region) Postgres box starting at $4 a month plus storage at $0.25 per GB, with backups and point-in-time recovery available on Personal and Team.

The database runs as a single private instance by default; opt-in public access and, on Team, high availability are per-database options when you need them.

Link the database to the Rails app. Ownkube writes its connection string into the app as a secret DATABASE_URL variable and redeploys it:

okctl deploy link rails-app <database-id>

Because config/database.yml already reads from ENV["DATABASE_URL"], no further Rails configuration is needed.

5. Set your secrets

Rails needs its master key or secret key base to decrypt credentials and sign sessions. Set it as a secret environment variable in the dashboard and keep config/master.key out of the repository:

okctl vars set rails-app RAILS_MASTER_KEY="$(cat config/master.key)" --secret
okctl vars set rails-app RAILS_ENV=production

If you use SECRET_KEY_BASE directly instead of the encrypted credentials file, set that instead:

okctl vars set rails-app SECRET_KEY_BASE="$(bundle exec rails secret)" --secret

Environment variables set through Ownkube are encrypted at rest and only injected into the running container.

6. Run migrations as a job

Run db:migrate as a one-off job instead of on every container start. Create a Job deployment from the same repository, set its command to bundle exec rails db:migrate, and leave the schedule empty. Variables are set per deployment, so give the job the same RAILS_MASTER_KEY and RAILS_ENV and link the same database to it.

Then trigger a run whenever a release includes new migrations:

okctl deploy link rails-migrate <database-id>
okctl deploy job-runs trigger rails-migrate
okctl deploy job-runs list rails-migrate

The run's output is on the job's Logs tab. The web app and the job deploy independently, so keep each migration safe for the version already running: add columns and tables in one release, and drop old ones in a later one.

7. Scale and watch it run

A fresh Rails app usually starts fine on a small metered ceiling, for example a 500m CPU limit and 1 GiB of memory, set on the sliders under Settings → Resources.

Turn on horizontal autoscaling if traffic is uneven, so Ownkube adds Puma instances under load and scales back down when it is quiet. On Ownkube Compute you turn it on through your coding agent (the update_deployment MCP tool) or the API, with a minimum and maximum replica count and a CPU target such as 70%.

Logs and metrics for the app and the database box are both in the dashboard, so a slow migration or a Puma worker that keeps restarting shows up in one place.

Moving to your own AWS later

If a customer contract requires the app to run in a named AWS account, your own or the customer's, the same Dockerfile and Rails app move there with no rewrite. Ownkube provisions the instance, wires up the same deploy flow, and brings the logs, metrics, and health checks with it.

Railway, by contrast, only runs on Railway's infrastructure. Our Railway alternatives guide compares Railway with the other options.

FAQ

Does Ownkube support Rails credentials and Active Storage?

Yes. Encrypted credentials work through RAILS_MASTER_KEY as shown above. Active Storage works against any S3-compatible bucket you configure; Ownkube does not provide managed object storage directly, so point it at your own bucket.

Do I need a Dockerfile, or can Ownkube detect Rails automatically?

A Dockerfile gives you full control over the Ruby version, native gems, and the asset precompile step, and is the most reliable path for Rails. Simpler apps without native dependencies can also deploy straight from source.

Can I run Sidekiq or another background worker alongside the web app?

Yes. Deploy the worker as a second Ownkube app pointed at the same Postgres connection string (and a Valkey cache box from $2 a month if you need Redis for the queue), so the web app and worker scale independently.

What happens if my wallet balance runs out mid-month?

The app pauses and its data, including the Postgres box, is kept. Adding credit or the next monthly plan load resumes it. Unused wallet credit rolls over and never expires, so credit from a quiet month carries into the next.

Can I roll back a bad deploy?

Yes. Ownkube keeps prior image versions and supports zero-downtime rollback from the dashboard or okctl, so a code issue does not require a manual recovery. A rollback restores the previous image, and a migration that already ran stays applied, so keep migrations additive.

For the always-current version of this walkthrough, see the Deploy Ruby on Rails guide in the docs. If you edit in Zed or work from Claude Code, connect it to Ownkube's MCP server and it can deploy the app and read its logs for you.

Where Ownkube fits

Rails wants a real database, a way to run migrations, and an app server that survives restarts, and Ownkube gives you all three without provisioning a cloud account first. Push the Dockerfile, attach a managed Postgres, set your secrets, and run migrations as a job. See Ownkube pricing for the per-minute wallet model, from $5 a month. Deploy my first app.

How to deploy a Next.js app on Ownkube

Abhishek Jaiswal — Sun, 01 Nov 2026 15:22:38 +0000

A Next.js app in a container needs one setting most tutorials skip: output: "standalone", which trims the build down to only the files next start actually needs instead of the full node_modules tree. Get that right and the rest of a Next.js deploy on Ownkube is a normal git push.

This walks through deploying a Next.js app (App Router or Pages Router, both work) on Ownkube Compute: the standalone build, environment variables split between build time and runtime, an optional managed Postgres for apps using an ORM, and automatic TLS.

TL;DR

Set output: "standalone" in next.config.js so the Docker image ships a minimal server instead of the whole node_modules folder.
Push the app with a Dockerfile, and Ownkube builds it, deploys it, and issues TLS automatically on your *.ownkube.app hostname.
NEXT_PUBLIC_* variables get baked into the build; everything else is a runtime environment variable set in the dashboard.
Add an Ownkube-managed Postgres database if you use Prisma or another ORM, and point the connection string at it.
Turn on horizontal autoscaling once traffic is uneven, since Next.js's SSR path is CPU-bound per request in a way static pages are not.

1. Enable standalone output

In next.config.js, add the standalone output mode:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "standalone",
};

module.exports = nextConfig;

This changes what next build produces. It emits a self-contained .next/standalone folder with only the files the server needs, plus a minimal server.js entry point, so the runtime no longer needs the full project and node_modules. That keeps the final Docker image small.

2. Write a Dockerfile

A multi-stage build keeps dependencies out of the final image:

FROM node:20-slim AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

FROM node:20-slim AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
# NEXT_PUBLIC_* values must be present at build time; they end up in the client bundle
ARG NEXT_PUBLIC_API_URL
ENV NEXT_PUBLIC_API_URL=$NEXT_PUBLIC_API_URL
RUN npm run build

FROM node:20-slim
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/.next/standalone ./
COPY --from=build /app/.next/static ./.next/static
COPY --from=build /app/public ./public

EXPOSE 3000
CMD ["node", "server.js"]

The build stage takes NEXT_PUBLIC_API_URL as a build argument because Next.js inlines NEXT_PUBLIC_* variables into the client JavaScript at build time. A value set only at runtime in the dashboard will not reach client-side code; it has to be present when npm run build runs.

3. Push the repo and create the app

Connect the repository from the Ownkube dashboard (app.ownkube.io) to deploy on every push, or deploy the current directory with the okctl CLI:

okctl login
okctl up --name nextjs-app --port 3000

Ownkube builds the image, allocates a hostname on *.ownkube.app, and issues TLS automatically, so there is no reverse proxy or certificate to set up by hand.

4. Set your environment variables

Split variables by when Next.js actually needs them:

# Server-only, read at runtime by API routes or Server Components
okctl vars set nextjs-app AUTH_SECRET="$(openssl rand -base64 32)" --secret

# Client-visible, baked into the bundle at build time, so set it as a build argument (see step 2)
okctl deploy build-args nextjs-app --arg NEXT_PUBLIC_API_URL="https://nextjs-app.ownkube.app/api"

Environment variables set through Ownkube are encrypted at rest and only injected into the running container, which is why a NEXT_PUBLIC_ value goes in as a build argument instead. Anything without the NEXT_PUBLIC_ prefix stays server-side and never ships to the browser.

5. Add a managed Postgres database, if you use an ORM

A Next.js app using Prisma, Drizzle, or another ORM for a database-backed API route needs a real Postgres instance. Create a database box from the dashboard: New > Database > Postgres, walked through in full in add a managed Postgres database to your app.

It provisions a private (in-region) Postgres box starting at $4 a month plus storage at $0.25 per GB, with backups and point-in-time recovery available on Personal and Team. The database runs as a single instance by default; you can turn on opt-in public access and, on Team, high availability (a primary plus up to two standby instances) per database when you need them.

Link the database to the app, and Ownkube writes its connection string into the app as a secret DATABASE_URL variable and redeploys it:

okctl deploy link nextjs-app <database-id>

With Prisma, generate the client in the build stage:

# In the build stage, after copying the schema
RUN npx prisma generate

Run prisma migrate deploy as a one-off job instead of in the build. Variables reach the running container rather than the build, and the database is private to its region, so the build cannot reach it.

The slim standalone image leaves out the Prisma CLI and your prisma folder, so give the job its own Dockerfile that installs dependencies and copies the schema, set its command to npx prisma migrate deploy, and link the same database to it. Then trigger it when a release includes new migrations:

okctl deploy link nextjs-migrate <database-id>
okctl deploy job-runs trigger nextjs-migrate

A purely static or content-fetching Next.js app can skip a database entirely.

6. Scale and watch it run

A fresh Next.js app usually starts fine on a small metered ceiling, for example a 500m CPU limit and 512 MiB of memory, set on the sliders under Settings → Resources.

Turn on horizontal autoscaling if traffic is uneven, so Ownkube adds server instances under load and scales back down when it is quiet. On Ownkube Compute you turn it on through your coding agent (the update_deployment MCP tool) or the API, with a minimum and maximum replica count and a CPU target such as 70%.

Server-side rendering and API routes are CPU work per request in a way a purely static export is not, so an SSR-heavy app benefits more from autoscaling headroom than a mostly-static one.

Metered billing charges CPU and memory on actual per-minute usage, so a quiet Next.js app between visits barely moves the wallet. Logs and metrics for the app live in the dashboard, so a slow render or a route that keeps erroring shows up in one place.

Moving to your own AWS later

If the app needs to run inside your own AWS account later, for compliance reasons or because a client wants their name on the infrastructure, the same Dockerfile and Next.js app move over with no rewrite. Ownkube provisions the instance, wires up the same deploy flow, and brings the logs, metrics, and health checks with it.

Railway only runs your app on its own infrastructure. Our Railway alternatives guide compares Railway with the other options.

FAQ

Do I need `output: "standalone"`, or does the default build work?

The default build works, but it expects the full project and node_modules present at runtime, which makes for a much larger Docker image and a slower deploy. Standalone output is the setting almost every Next.js Docker guide converges on, and it is the one used in the Dockerfile above.

Does Ownkube support the App Router and Server Actions?

Yes, both the App Router and the older Pages Router run the same way, since next start in the standalone build serves whatever the app builds. Server Actions run as part of the same Node process and read server-side environment variables normally.

How do I handle a value that is different between preview and production?

Set the environment variable per app in the dashboard or with okctl vars set <app> NAME=VALUE, and use a separate Ownkube app for each environment you want isolated, each with its own hostname, environment variables, and (if needed) database.

What happens if my wallet balance runs out mid-month?

The app pauses and any attached database keeps its data. Adding credit or the next monthly plan load resumes it. Unused wallet credit rolls over and never expires.

Can I use a custom domain?

An automatic *.ownkube.app hostname with TLS is provisioned for every app the moment it deploys, so you always have a working URL with no configuration. On Personal and Team you can also add your own domain to the app. You set two DNS records and Ownkube issues and renews the certificate. See Custom domains.

Should I host Next.js on Vercel instead?

For a personal, non-commercial frontend, Vercel's Hobby plan is free and runs Next.js well. A commercial project needs Pro at $20 per developer seat a month. Is Vercel free? covers the Hobby rules. Ownkube fits when the app needs a long-running server, workers or Postgres next to it.

For the always-current version of this walkthrough, see the Deploy Next.js guide in the docs. Node.js hosting covers the other Node frameworks, and if you work in Cursor or GitHub Copilot, the editor can deploy the app and check its build logs through Ownkube's MCP server.

Where Ownkube fits

Next.js wants a slim server image, a clean split between build-time and runtime configuration, and a database only when the app actually uses one, and Ownkube gives you all three without provisioning a cloud account first. Set standalone output, push the Dockerfile, set your environment variables, and the hostname and TLS are already waiting. See Ownkube pricing for the per-minute wallet model, from $5 a month. Deploy my first app.

How to deploy a FastAPI app on Ownkube

Abhishek Jaiswal — Sun, 01 Nov 2026 15:07:31 +0000

FastAPI is fast to run locally with uvicorn app.main:app --reload, and the production version of that command is not much longer. Production adds three things: a process manager that restarts a crashed worker, config read from environment variables instead of a .env file in the repo, and a health check for the platform to poll. Ownkube handles the rest from a git push.

This walks through deploying a FastAPI app on Ownkube Compute: running Gunicorn with Uvicorn workers, configuring settings through environment variables, adding a health check endpoint, and turning on autoscaling.

TL;DR

Push a FastAPI app with a Dockerfile, and Ownkube builds it, deploys it, and issues TLS automatically on your *.ownkube.app hostname.
Run Gunicorn with uvicorn.workers.UvicornWorker in production rather than Uvicorn's dev server directly, so a crashed worker restarts instead of taking the app down.
Load configuration through a Pydantic BaseSettings class and set the real values as environment variables in the dashboard, never in the repo.
Add a Postgres database only if the app needs one; a stateless API can skip it entirely.
Expose a /health route and turn on horizontal autoscaling once traffic is uneven.

1. Structure the app for a container

A typical FastAPI project layout works as-is:

app/
  __init__.py
  main.py
  config.py
  routers/
requirements.txt
Dockerfile

Load configuration through pydantic-settings so every value has a typed default and a clear environment variable name:

# app/config.py
from pydantic_settings import BaseSettings

class Settings(BaseSettings):
    database_url: str | None = None
    environment: str = "production"
    cors_origins: list[str] = []

    class Config:
        env_file = None  # read only from real environment variables in production

settings = Settings()

Add a health check route, a few lines that give Ownkube something reliable to check the container against:

# app/main.py
from fastapi import FastAPI
from app.config import settings

app = FastAPI()

@app.get("/health")
def health():
    return {"status": "ok"}

2. Write a Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

ENV PYTHONUNBUFFERED=1
EXPOSE 8000

CMD ["gunicorn", "app.main:app", \
     "--worker-class", "uvicorn.workers.UvicornWorker", \
     "--bind", "0.0.0.0:8000", \
     "--workers", "4", \
     "--timeout", "60"]

Gunicorn in front of Uvicorn workers is the standard production pairing: Gunicorn manages the worker pool and restarts a worker that dies, and each worker runs Uvicorn's ASGI event loop. Running uvicorn directly with no process manager is fine for a demo. A container that needs to survive a bad request or an unhandled exception wants the supervisor.

Add requirements.txt:

fastapi
uvicorn[standard]
gunicorn
pydantic-settings

3. Push the repo and create the app

Connect the repository from the Ownkube dashboard (app.ownkube.io) to deploy on every push, or deploy the current directory with the okctl CLI:

okctl login
okctl up --name fastapi-app --port 8000

Ownkube builds the image, allocates a hostname on *.ownkube.app, and issues TLS automatically. If the repo has no Dockerfile, Ownkube's automatic build detects Python and builds an image for you, though a Dockerfile gives more control over the worker command above.

4. Add a managed Postgres database, if you need one

Plenty of FastAPI services are stateless: they call out to another API and return a response, and nothing needs to persist. If that describes your app, skip this step.

If the app does need a database, create a database box from the dashboard: New > Database > Postgres. It provisions a private (in-region) Postgres box starting at $4 a month plus storage at $0.25 per GB, with backups and point-in-time recovery available on Personal and Team. The database runs as a single instance by default; opt-in public access and, on Team, high availability are per-database options.

Link the database to the app. Ownkube writes its connection string into the app as a secret DATABASE_URL variable and redeploys it. Read it through settings:

okctl deploy link fastapi-app <database-id>

# app/config.py
class Settings(BaseSettings):
    database_url: str | None = None

The linked URL starts with postgresql://, and SQLAlchemy's async engine wants the postgresql+asyncpg:// scheme, so swap it when you create the engine:

from sqlalchemy.ext.asyncio import create_async_engine

engine = create_async_engine(
    settings.database_url.replace("postgresql://", "postgresql+asyncpg://", 1),
    pool_pre_ping=True,
)

5. Set your configuration as environment variables

Anything the Pydantic Settings class reads should come from the dashboard instead of a committed .env file:

okctl vars set fastapi-app ENVIRONMENT=production CORS_ORIGINS="https://yourapp.com"

Environment variables set through Ownkube are encrypted at rest and only injected into the running container, so secrets like API keys or a database password never live in the repo or the image.

6. Scale and watch it run

A fresh FastAPI service usually starts fine on a small metered ceiling, for example a 500m CPU limit and 512 MiB of memory, set on the sliders under Settings → Resources.

Turn on horizontal autoscaling once traffic is uneven, so Ownkube adds Uvicorn worker instances under load and scales back down when it is quiet. On Ownkube Compute you turn it on through your coding agent (the update_deployment MCP tool) or the API, with a minimum and maximum replica count and a CPU target such as 70%.

Metered billing suits an API that idles between bursts: it charges CPU and memory on actual per-minute usage, so a service that sits quiet overnight barely draws the wallet down.

If the service instead runs hot around the clock, for example a worker consuming a queue continuously, a flat Spark box is a steadier price than metering a constant load. Logs and metrics for the app live in the dashboard, so a worker that keeps restarting or a slow endpoint shows up in one place.

Moving to your own AWS later

If the service needs to run inside your own or a customer's AWS account, the same Dockerfile and FastAPI app move there with no rewrite. Ownkube provisions the instance, wires up the same deploy flow, and brings the logs, metrics, and health checks with it. Railway only runs on its own infrastructure. Our Railway alternatives guide compares Railway with the other options.

FAQ

Should I use Uvicorn directly or Gunicorn with Uvicorn workers?

Use Gunicorn with uvicorn.workers.UvicornWorker in production. Gunicorn manages the worker pool, restarts a worker that crashes, and gives you a --workers count to tune; running Uvicorn alone has none of that supervision.

Does Ownkube support WebSockets?

Yes, a Uvicorn worker handles WebSocket connections the same way it does in any other deployment. Keep in mind that autoscaling adds new instances rather than new connections to an existing one, so a long-lived WebSocket workload should size --workers and the autoscale ceiling with connection count in mind as well as CPU.

How does Ownkube know my app is healthy?

Health checks on the app's Settings tab poll /health by default, and Ownkube restarts the container when the liveness check keeps failing. A lightweight /health route that does not touch the database gives it a fast, reliable signal, separate from a /status endpoint that might check dependencies and take longer to answer.

What happens if my wallet balance runs out mid-month?

The app pauses and any attached database keeps its data. Adding credit or the next monthly plan load resumes it. Unused wallet credit rolls over and never expires.

Can I run a background worker alongside the API?

Yes. Deploy it as a second Ownkube app or as a scheduled job if the work runs on a cadence rather than continuously, and point it at the same Postgres connection string if it shares data with the API.

For the always-current version of this walkthrough, see the Deploy FastAPI guide in the docs. Codex and Windsurf can also run the deploy through Ownkube's MCP server, from the same session where you wrote the API.

Where Ownkube fits

FastAPI wants a process manager that survives a crashed worker, config that stays out of the repo, and a place to add a database only when the app actually needs one, and Ownkube gives you all three without provisioning a cloud account first. Push the Dockerfile, set your environment variables, and turn on autoscaling when traffic gets uneven.

See Ownkube pricing for the per-minute wallet model, from $5 a month. Deploy my first app.

How to deploy a Django app on Ownkube

Abhishek Jaiswal — Sun, 01 Nov 2026 14:52:24 +0000

A Django app in production needs four things from a host: a real WSGI server in front of it, a Postgres database it can reach, static files served correctly, and a way to run migrations before code that needs them takes traffic. Ownkube covers all four without a cloud account or hand-written YAML.

This walks through deploying a standard Django app on Ownkube Compute: swapping the dev server for Gunicorn, wiring up a managed Postgres, handling static files with WhiteNoise, and running migrate as a job.

TL;DR

Push a Django app with a Dockerfile, and Ownkube builds it, deploys it, and issues TLS automatically on your *.ownkube.app hostname.
Add an Ownkube-managed Postgres database and point DATABASE_URL at it with dj-database-url or the equivalent.
Serve static files with WhiteNoise instead of standing up a separate static host, and run collectstatic in the Docker build.
Set SECRET_KEY, DJANGO_SETTINGS_MODULE, and ALLOWED_HOSTS as environment variables in the dashboard, not in the repo.
Run migrate as a one-off job, so it runs once per release instead of on every container start.

1. Prepare settings for production

Most of this is standard Django. Point the database and static file settings at environment variables instead of hardcoded values:

# settings.py
import os
import dj_database_url

DEBUG = False
SECRET_KEY = os.environ["SECRET_KEY"]
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")

DATABASES = {
    "default": dj_database_url.config(env="DATABASE_URL", conn_max_age=600)
}

STATIC_URL = "/static/"
STATIC_ROOT = "/app/staticfiles"
STORAGES = {
    "staticfiles": {
        "BACKEND": "whitenoise.storage.CompressedManifestStaticFilesStorage",
    },
}

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",
    # ...the rest of your middleware
]

Add whitenoise, gunicorn, psycopg[binary], and dj-database-url to requirements.txt. WhiteNoise lets a small app serve its own CSS and JS without a separate static file host or CDN.

2. Write a Dockerfile

Ownkube deploys from a Dockerfile when the repo has one, so you get full control over the Python version and the build steps:

FROM python:3.12-slim

RUN apt-get update -qq && apt-get install -y libpq-dev build-essential \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

# Collect static files at build time, before SECRET_KEY exists at runtime
RUN SECRET_KEY=build-only DATABASE_URL=sqlite:///build.db \
    python manage.py collectstatic --noinput

ENV PYTHONUNBUFFERED=1
EXPOSE 8000

CMD ["gunicorn", "myproject.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "3"]

Gunicorn's worker count is a starting point. A CPU-bound app usually wants workers close to (2 x vCPU) + 1; an I/O-bound app that mostly waits on the database can run more workers per vCPU than that rule suggests.

3. Push the repo and create the app

Connect the repository from the Ownkube dashboard (app.ownkube.io) to deploy on every push, or deploy the current directory with the okctl CLI:

okctl login
okctl up --name django-app --port 8000

Ownkube builds the image from your Dockerfile, allocates a hostname on *.ownkube.app, and issues TLS automatically, so there is no load balancer or certificate to configure by hand. Running okctl up again ships the next version.

4. Add a managed Postgres database

The database runs as a single private instance by default, which is the normal shape for a small to mid-size Django app; opt-in public access and, on Team, high availability are per-database options when you need them.

Link the database to the app. Ownkube writes its connection string into the app as a secret DATABASE_URL variable and redeploys it:

okctl deploy link django-app <database-id>

dj_database_url.config() in settings.py reads it directly, so there is no further Django-side configuration.

5. Set your secrets

Django needs SECRET_KEY to sign sessions and cookies, and it will refuse to run with DEBUG=False and an empty ALLOWED_HOSTS. Set these as environment variables in the dashboard and keep them out of the repository:

okctl vars set django-app SECRET_KEY="$(python -c 'import secrets; print(secrets.token_urlsafe(50))')" --secret
okctl vars set django-app DJANGO_SETTINGS_MODULE=myproject.settings ALLOWED_HOSTS="django-app.ownkube.app"

Environment variables set through Ownkube are encrypted at rest and only injected into the running container.

6. Run migrations as a job

Run migrate as a one-off job instead of on every container start. Create a Job deployment from the same repository, set its command to python manage.py migrate --noinput, and leave the schedule empty. Variables are set per deployment, so give the job the same SECRET_KEY and DJANGO_SETTINGS_MODULE and link the same database to it.

Then trigger a run whenever a release includes new migrations:

okctl deploy link django-migrate <database-id>
okctl deploy job-runs trigger django-migrate
okctl deploy job-runs list django-migrate

7. Scale and watch it run

A fresh Django app usually starts fine on a small metered ceiling, for example a 500m CPU limit and 1 GiB of memory, set on the sliders under Settings → Resources.

Turn on horizontal autoscaling if traffic is uneven, so Ownkube adds Gunicorn instances under load and scales back down when it is quiet. On Ownkube Compute you turn it on through your coding agent (the update_deployment MCP tool) or the API, with a minimum and maximum replica count and a CPU target such as 70%.

Metered billing fits a typical Django app well: it charges CPU and memory on actual per-minute usage, and a Django app sitting between requests barely registers on the CPU line.

Logs and metrics for the app and the database box both live in the dashboard, so a slow migration or a worker that keeps restarting shows up in one place.

Moving to your own AWS later

If a client's security review asks for the app to run in a named AWS account, your own or theirs, the same Dockerfile and Django app move there with no rewrite. Ownkube provisions the instance, wires up the same deploy flow, and brings the logs, metrics, and health checks with it.

Railway, by contrast, only runs your workload on its own infrastructure. Our Railway alternatives guide compares Railway with the other options.

FAQ

Does Ownkube support Django's admin site and management commands?

Yes. The admin works like any other Django view once ALLOWED_HOSTS and static files are configured. One-off management commands run as a one-off job, started from the job's Runs tab or with okctl deploy job-runs trigger, instead of inside a running web container.

Do I need a Dockerfile, or can Ownkube detect Django automatically?

A Dockerfile gives you control over the Python version, system packages like libpq-dev, and the collectstatic build step, and is the most reliable path for Django. Simpler apps without native dependencies can also deploy straight from source using Ownkube's automatic build.

Can I run Celery or another background worker alongside the web app?

Yes. Deploy the worker as a second Ownkube app pointed at the same Postgres connection string, and add a Valkey cache box from $2 a month if you need Redis as the broker, so the web app and worker scale independently.

What happens if my wallet balance runs out mid-month?

Can I roll back a bad deploy?

Yes. Ownkube keeps prior image versions and supports zero-downtime rollback from the dashboard or okctl, so a broken release or settings change does not require a manual recovery. A rollback restores the previous image, and a migration that already ran stays applied, which is one more reason to keep migrations additive.

For the always-current version of this walkthrough, see the Deploy Django guide in the docs. To hand the deploy to an assistant, connect Claude Code or Claude Desktop to Ownkube's MCP server and ask it to deploy the app, add Postgres and read the logs.

Where Ownkube fits

Django wants a real database, a way to run migrations, and a place to serve static files without standing up a separate CDN, and Ownkube gives you all three without provisioning a cloud account first. Push the Dockerfile, attach a managed Postgres, set your secrets, and run migrations as a job. See Ownkube pricing for the per-minute wallet model, from $5 a month. Deploy my first app.

Kubernetes alternatives for small teams in 2026

Abhishek Jaiswal — Sun, 01 Nov 2026 14:37:18 +0000

Kubernetes is the standard way large organizations run containers, and it earns that place: it schedules thousands of workloads across machines, rolls out new versions safely, heals what crashes, and gives many teams one shared API.

A team of three to twenty engineers with a handful of services needs the outcomes, and much less of the machinery. This post lists what Kubernetes actually gives you, what it costs a small team to own, and the alternatives that deliver the same outcomes with less to run.

TL;DR

Most small teams need five things from Kubernetes: rolling deploys, restarts on crash, autoscaling, private networking between services, and HTTPS on a hostname. Every alternative below provides them.
The cost of Kubernetes for a small team is mostly time: upgrades on the release cycle, cluster add-ons, YAML, and someone who knows how it all fits together.
A managed developer platform (a PaaS) is the shortest path. Managed container services suit teams already deep in one cloud. A self-hosted PaaS or Docker Compose on one server is cheapest in cash and costs you the operations.
Keep Kubernetes when you have a platform team, custom operators, strict placement or compliance needs, or many teams sharing one cluster.

What does Kubernetes give you?

What you need	How Kubernetes does it	How a simpler platform does it
Ship a new version safely	Rolling updates with readiness probes	Rolling deploys with health checks, one-click rollback
Keep the app running	Restarts failed containers, reschedules on node loss	Restarts the process, moves it on host failure
Handle more traffic	Horizontal autoscaling on CPU or memory	Autoscaling on CPU or memory, set in a form
Services talk to each other	Service discovery and cluster DNS	A private network inside the project or environment
HTTPS on a hostname	An ingress controller plus certificate automation	Automatic TLS on a generated or custom hostname
Config and secrets	ConfigMaps and Secrets	Environment variables with a secret toggle
Scheduled tasks	CronJobs	Scheduled jobs

Everything in the right-hand column is a feature you turn on. Everything in the middle column is something you install, configure, upgrade and debug.

What does Kubernetes cost a small team?

The cluster bill is the visible part. The larger cost is attention.

Upgrades never stop

Kubernetes ships three minor releases a year, and each is supported for about fourteen months. Staying on a supported version means an upgrade, with its deprecations, every few months.

The add-ons are yours

An ingress controller, certificate automation, DNS automation, a metrics stack, log shipping, a secrets operator and an autoscaler for nodes each have their own release cycle and failure modes.

YAML is the interface

Every app needs deployments, services, ingress rules, autoscalers and policies, usually templated through Helm charts that someone has to maintain.

Someone has to understand it

When a rollout hangs at 2 a.m., the team needs a person who can read events, describe pods and reason about the scheduler. For many small teams that person is the CTO, or a DevOps hire at a full salary.

The DevOps engineer cost guide prices that role, and the hire vs platform calculator compares it with a platform.

At scale that work pays for itself. At five services, it is overhead.

What are the alternatives to Kubernetes?

1. A managed developer platform

Render, Railway, Fly.io, Heroku and Ownkube run your containers for you. You connect a repository, pick a service type (web app, worker, cron job), add a database, and the platform handles builds, rollouts, TLS, scaling and logs. This is the shortest path from code to production and the one most small teams should try first.

The trade-offs are pricing models and how much control you keep, which the Railway alternatives guide and Railway vs Render vs Northflank compare in detail.

2. Managed container services from a cloud provider

AWS ECS with Fargate, Google Cloud Run and Azure Container Apps run containers without a cluster to manage. They fit teams that already live in one cloud and want its networking, identity and billing. You still assemble the pieces: load balancers, certificates, secrets, log routing and a deploy pipeline are separate services you wire together, often in infrastructure-as-code.

3. A self-hosted PaaS on your own server

Coolify, Dokploy, CapRover and Dokku give you a Heroku-style interface on a server you rent. Kamal deploys containers to your servers over SSH. The cash cost is the server, and the operations (OS patches, backups, disk space, the PaaS itself) are yours. The Coolify alternatives guide compares them.

4. Docker Compose on one server

A single server running Docker Compose behind a reverse proxy is the simplest production setup there is. It is a good choice for internal tools and early products. It has no rolling deploys or failover by default, so a bad deploy or a dead server is downtime until you fix it.

5. HashiCorp Nomad

Nomad schedules containers and plain binaries across machines with a much smaller surface than Kubernetes. It suits teams that want a real scheduler across several servers and are comfortable running it, usually alongside Consul for service discovery.

How do I choose?

Your situation	Good fit
Small team, a few services, want to ship today	A managed developer platform
Already standardized on one cloud, have infrastructure-as-code	ECS with Fargate, Cloud Run or Container Apps
Tight cash budget, someone enjoys running servers	A self-hosted PaaS or Docker Compose
Several servers, want a scheduler, prefer a small tool	Nomad
Platform team, many teams, custom operators, strict placement rules	Kubernetes

When is Kubernetes the right call?

Keep or adopt Kubernetes when at least one of these is true:

You have a platform team whose job is the cluster.
Many product teams share infrastructure and need one API with quotas and policy.
You rely on operators or custom resources that only exist for Kubernetes.
Compliance or customers require workloads in specific accounts, regions or machines with fine-grained control.
You run GPU or batch workloads that need the scheduler's placement features.

FAQ

Is Kubernetes overkill for a startup?

For most early startups, yes. A startup with a few services needs rolling deploys, restarts, autoscaling, private networking and HTTPS, and a managed developer platform provides all of them without a cluster to upgrade. Kubernetes starts to pay off when you have a platform team or many teams sharing infrastructure.

What is the simplest alternative to Kubernetes?

Docker Compose on one server is the simplest to set up, and a managed developer platform is the simplest to run in production, because rollouts, TLS, scaling and failover are handled for you.

Can I run microservices without Kubernetes?

Yes. Each service becomes its own deployment on a platform, and services reach each other over a private network by name. On Ownkube, a Go service and a Java app like the Spring PetClinic template deploy the same way, each with its own Postgres if it needs one. Most platforms also run workers and scheduled jobs, which covers the usual microservice shapes.

Do I need Kubernetes to autoscale?

No. Managed developer platforms and cloud container services autoscale on CPU or memory. On Ownkube you set a minimum and maximum replica count and a CPU target, through your coding agent or the API.

Is Docker Compose good enough for production?

For internal tools and early products on one server, often yes. Plan for backups, a reverse proxy with TLS, and a way to roll back, because Compose has no rolling deploys or failover across machines by default.

Where Ownkube fits

Ownkube is a developer platform for small teams that want the outcomes of Kubernetes without operating it. Push a repo and get builds, rolling deploys with health checks, autoscaling on CPU, private networking, automatic HTTPS, managed Postgres and a Valkey cache, logs, metrics and one-click rollbacks.

Usage bills per minute from a prepaid wallet, and unused credit never expires. When a customer needs the app in their own cloud, the same app ships there with its observability intact. Deploy my first app.

Railway vs Vercel in 2026: frontend platform or backend host?

Abhishek Jaiswal — Sun, 01 Nov 2026 14:22:12 +0000

Railway and Vercel show up in the same searches, and they overlap less than it seems. Vercel is a frontend cloud: it builds Next.js and other frameworks, serves them from a global edge network, and runs your server code as functions that start per request. Railway runs long-lived containers: API servers, workers, cron jobs and databases that stay up between requests. Many teams use both.

This post explains where each fits, compares the limits and pricing that matter, and covers the split setup. Prices and limits were checked on 2026-10-13.

TL;DR

Vercel is the better home for a Next.js or other frontend: preview deployments per branch, a global CDN, image optimization and zero server management. Server code runs as functions with a duration limit of 300 seconds on Hobby and 800 on Pro.
Railway is the better home for anything long-running: API servers, WebSocket servers, queue workers, bots, cron jobs and databases.
Vercel's Hobby plan is free for personal, non-commercial use. Pro is $20 per seat a month with $20 of usage included. Railway Pro is $20 per workspace with $20 of usage included.
A common setup is the frontend on Vercel and the API and Postgres on Railway, in nearby regions.

What is each one built for?

	Vercel	Railway
Core model	Static assets on a CDN plus functions per request	Containers that run continuously
Best at	Next.js, frontends, server rendering, edge middleware	APIs, workers, cron jobs, databases, bots
Server code	Functions with a maximum duration	Any process, no time limit
WebSockets	Public beta on Vercel Functions	Supported natively by any server
Databases	Through Marketplace integrations, billed by the provider	Postgres, MySQL, Redis and others as services in your project
Background jobs	Cron jobs that call functions; Workflows for long tasks	Workers and cron services

What are Vercel's function limits?

Vercel Functions run with these limits on fluid compute:

	Hobby	Pro
Maximum duration	300 seconds	800 seconds, 1800 in beta
Maximum memory	2 GB, 1 vCPU	4 GB, 2 vCPU
Request or response body	4.5 MB	4.5 MB

Anything that has to run longer, hold a connection open for hours, or keep state in memory between requests fits a long-running server like Railway better.

How do Railway and Vercel price?

	Vercel	Railway
Free	Hobby: free for non-commercial use, with included limits	Free plan: $1 of credit a month after a $5 trial
Paid plan	Pro: $20 per seat a month, $20 of usage included	Hobby $5 with $5 of usage; Pro $20 per workspace with $20 of usage
Compute	Active CPU from $0.128 per hour, memory from $0.0106 per GB-hour	about $20 per vCPU and $10 per GB a month
Requests	Invocations from $0.60 per million	Included
Bandwidth	1 TB on Pro, then from $0.15 per GB	$0.05 per GB

The per-seat model is the line to watch. A team of five on Vercel Pro pays $100 a month in seats before usage. Railway's Pro fee is per workspace.

Can Railway host Next.js?

Yes. Railway runs Next.js as a Node server with next start, including server rendering, API routes and middleware. You give up Vercel's per-branch preview URLs on its global edge, image optimization at the CDN, and the zero-configuration build, and you gain a server with no function time limits and flat usage pricing.

Can Vercel host my backend?

For an API made of short request handlers, yes: Vercel Functions run Node.js, Python, Go and other runtimes. It stops fitting when you need a process that runs continuously, a queue consumer, a Discord bot, a server holding many WebSocket connections, or a database. Those need a host like Railway.

How do I use Vercel and Railway together?

Deploy the frontend to Vercel and the API, workers and Postgres to Railway.
Pick regions close to each other. Vercel Functions run in a single region by default, so match your Railway region to it to keep each API call short.
Point the frontend at the API with an environment variable, and allow the Vercel domain in the API's CORS settings.
Keep secrets for the database on the Railway side only. The frontend talks to your API, never to the database directly.

Railway or Vercel: which should you pick?

If you are building	Pick
A Next.js marketing site or frontend	Vercel
A REST or GraphQL API with Postgres	Railway
A full-stack Next.js app with a database	Vercel for the app plus a database provider, or Railway for both
Workers, bots, cron jobs	Railway
A commercial project on a free plan	Neither: Vercel Hobby is non-commercial, and Railway's free credit is $1 a month

The Vercel alternatives guide covers more backend options next to Vercel, including Netlify.

FAQ

Is Railway a Vercel alternative?

For backends and long-running services, yes. For frontends, Railway can run Next.js as a server, but it lacks Vercel's global edge network and per-branch preview URLs on a CDN. Many teams use Vercel for the frontend and Railway for the backend.

Can I use Vercel Hobby for a commercial project?

No. Vercel's Hobby plan is for personal, non-commercial use. Commercial projects need Pro at $20 per seat a month.

Does Vercel support WebSockets?

WebSocket support on Vercel Functions is in public beta on all plans. For a server that holds many long-lived connections, a long-running host is still the more predictable choice.

Which is cheaper, Railway or Vercel?

They bill different things. For a frontend with mostly static pages, Vercel's included usage often covers it. For an always-on API or worker, Railway's metered containers are cheaper than keeping functions busy, and Railway does not charge per seat.

Where Ownkube fits

Ownkube is a backend host in the Railway mold: web apps, workers, cron jobs, managed Postgres and a Valkey cache, built from your repo and served on a *.ownkube.app hostname with HTTPS. It runs next to a Vercel frontend the same way Railway does.

Usage bills per minute from a prepaid wallet at about $18 per vCPU and $6 per GiB a month, with no per-seat fee, and unused credit never expires. Deploy my first app.

Replit alternatives: where to build and host your app instead

Abhishek Jaiswal — Sun, 01 Nov 2026 14:07:05 +0000

Replit puts three things on one bill: a browser workspace, the Replit Agent that writes code for you, and hosting for the app it builds. The right alternative depends on which of those you want to replace. Lovable and Bolt replace the agent and the workspace. Cursor or Claude Code in your own editor replaces both with tools you run locally. Render, Railway, Fly.io and Ownkube replace the hosting, which is where most of a running app's bill ends up.

Our picks

If you want	Pick
Another browser AI builder with hosting included	Lovable or Bolt
To write code with an AI agent in your own editor	Cursor or Claude Code, deployed anywhere below
The app, workers, cron jobs and Postgres on one prepaid bill	Ownkube
A few steady services at flat monthly prices	Render
Fast setup for several small services	Railway
Servers close to users on several continents	Fly.io
A frontend on a global CDN	Vercel

What Replit costs

Plan	Price	What it adds
Starter	$0	Daily Agent credits up to a monthly cap, one published app
Core	$20 a month, or $18 billed annually	Unlimited published apps, Full build, pay as you go past the credits
Pro	$100 a month, or $90 billed annually	10 parallel agents, up to 15 collaborators
Enterprise	Custom	Security and admin controls

The Starter plan's published app goes down after 30 days unless you publish it again, and it carries a Replit badge. Starter also gets Lite build only. Full build needs Core or Pro.

Publishing bills against the plan's monthly credits first, then as usage:

Deployment type	Price
Autoscale	$2 a month base, $0.60 per million compute units, $0.40 per million requests
Reserved VM	$15 a month (0.5 shared vCPU, 2 GB) up to $130 (4 vCPU, 16 GB)
Static	Free hosting, $0.05 per GB of transfer
Scheduled	$2 a month base, $0.60 per million compute units

A compute unit is 1/18 of a CPU second, or half a GB-second of memory. Agent usage bills by effort, so a long building session draws more credit than a short fix.

Why people look for a Replit alternative

The agent and the app share one balance

Agent work and running apps both draw on the same credits. A busy week of building can use credit that would have kept the app online, and the cost of an Agent session is hard to know before it runs.

The free app expires

On Starter, a published app goes down after 30 days. That works for a demo. For anything people rely on, it means a paid plan or another host.

The region is fixed at publish

Paid plans can pick where an app runs, and Starter apps publish to North America by default. Once an app is published, its geography can't be changed. Moving it means a new deployment.

You want your code in your own tools

Some people start in Replit and then want a local editor, their own git workflow and a coding agent they already pay for. At that point Replit's workspace and hosting are separate decisions.

The alternatives, one by one

Lovable

Lovable is the closest match to the Replit Agent workflow: describe the app in a chat and it builds it, with hosting on Lovable Cloud. The free plan gives 5 build credits a day, up to 30 a month, plus 20 Cloud credits a month. Paid monthly credits expire two months after they are issued. Small apps usually host within the included grant, and larger or busier ones draw from your credit balance. See Lovable's pricing.

Bolt

Bolt builds apps from a prompt in the browser and hosts them on every plan. The free plan has 1 million tokens a month with a 300,000 daily limit, and no custom domain. Pro is $25 a month for 10 million tokens that roll over, and Teams is $30 per member a month. See Bolt's pricing.

Cursor or Claude Code, in your own editor

These are coding agents that work on a repository on your machine. They write and edit code the way the Replit Agent does, but the code lives in your git repo and the hosting is your choice. Both can connect to Ownkube's MCP server and deploy the app, read logs and manage the database from the same session. The setup steps are on the Claude Code and Cursor pages.

Render

Render runs always-on services at flat monthly prices. The Hobby workspace is $0 and compute bills on top: a web service starts at $7 a month for 0.5 CPU and 512 MB, and Postgres starts at $6. A free instance exists for trying things out, and it spins down when idle. Render pricing explained has the full rate card.

Railway

Railway bills usage per second. Hobby is $5 a month and includes $5 of usage, and there is a Free plan with $1 of monthly credit. It is quick to set up several services and a database from one project. See Railway pricing explained.

Fly.io

Fly.io runs machines in many regions, which suits apps whose users are spread across continents. The smallest machine is $2.19 a month for a shared CPU and 256 MB, and managed Postgres starts at $38 a month. See Fly.io pricing explained for the rate card.

Vercel

Vercel is the pick for a Next.js or static frontend. Hobby is free for personal, non-commercial projects, and Pro is $20 per developer seat a month. Server code runs as functions with time limits, so a worker or a long job needs another host. Is Vercel free? covers the Hobby rules.

Ownkube

Ownkube runs the whole app: web services, workers, scheduled jobs, Postgres from $4 a month and a Valkey cache from $2. Compute is metered at about $18 per vCPU a month and $6 per GiB, by the minute, or you pick a flat box per app. Apps run in Mumbai or Germany. Ownkube has no AI of its own; you bring the agent.

Replit vs Ownkube

	Replit	Ownkube
Where you write code	Replit's browser workspace	Your own editor and repo
AI	Replit Agent, billed by effort	Your own coding agent, connected through MCP
Always-on app	Reserved VM from $15 a month	Metered from about $7.50 a month (0.25 vCPU, 0.5 GiB)
Postgres	Built in, billed from credits	From $4 a month plus $0.25 per GB
Background work	Reserved VMs and scheduled deployments	Workers and scheduled jobs
Billing	Plan credits, then pay as you go	Prepaid wallet; apps pause when it runs out

The wallet is the main difference in how the bill behaves. Pay as you go starts with a $5 top-up, Personal is $5 a month and loads $5 of credit, and Team is $20 a month and loads $20. Credit never expires. When it runs out, apps pause and keep their data until you top up, so a month can't cost more than you loaded.

Sleep is opt-in. An idle app bills nothing for compute and a sleeping database bills storage only.

Moving an app off Replit

Push the code from Replit to a GitHub repository.
Copy the values from Replit's Secrets into a note you can paste from.
Create the new app from the repo in the Ownkube dashboard, or run okctl up in the project directory.
Add the secrets as variables on the app.
Create a Postgres database, then move the data with pg_dump and pg_restore.
Point the app's database URL at the new database and redeploy.

When to stay on Replit

Stay if you mostly build with the Replit Agent and like working in the browser. Replit keeps the agent, the workspace and hosting in one place, and splitting them adds steps. A prototype that only needs to run for a demo also fits the Starter plan well.

A checklist before you move

Which part do you want to replace: the agent, the workspace, the hosting, or all three?
Does the app need to stay online for more than 30 days?
Do you need a worker or a job that runs longer than a request?
Where are your users, and which regions does the new host offer?
Do you want a hard ceiling on what a month can cost?

FAQ

What is the best free alternative to Replit?

For building with an AI agent in the browser, Lovable and Bolt both have free plans. For hosting, Render has a free instance that spins down when idle and Railway has a Free plan with $1 of monthly credit.

Is Replit free?

The Starter plan is $0 with daily Agent credits and one published app. That app goes down after 30 days unless you publish it again.

How much does Replit hosting cost?

A Reserved VM starts at $15 a month for 0.5 of a shared vCPU and 2 GB. Autoscale has a $2 monthly base plus compute units and requests. Static hosting is free with $0.05 per GB of transfer.

Can I export my code from Replit?

Yes. Push it to a GitHub repository and deploy it from there on any host in this list.

Can I keep using an AI agent after leaving Replit?

Yes. Claude Code, Cursor, Codex and Windsurf work on your own repo, and each can connect to Ownkube's MCP server, so the agent that writes the code can also deploy it.

Where Ownkube fits

If Replit got your app built and you now want it hosted with its Postgres, workers and cron jobs on one prepaid bill, Ownkube runs it in Mumbai or Germany. Bring the code from GitHub and the agent you already use. Deploy my first app.

Supabase vs Firebase: database, pricing, auth and lock-in compared

Abhishek Jaiswal — Sun, 01 Nov 2026 13:51:58 +0000

Supabase and Firebase both give a frontend a database, auth, file storage and functions without running a server. The difference starts with the database. Supabase is Postgres, with tables, joins and SQL, and it bills a plan fee plus compute size. Firebase is Firestore, a document store with offline sync, and it bills per document read and write. Pick Supabase if your data is relational or you want to keep the option to leave. Pick Firebase if you are building a mobile app that leans on offline sync and Google's mobile tools.

TL;DR

Supabase is Postgres. Firebase's main database, Firestore, stores documents and has no joins.
Supabase Pro is $25 a month and includes $10 of compute credit. Firebase Blaze has no base fee and bills each read, write and GB.
Both free plans include 50,000 monthly active users for auth. Supabase Free pauses a project after a week of inactivity, and Firebase Spark caps Firestore at 50,000 reads a day.
Supabase Pro has a spend cap on by default for usage lines. Firebase has budget alerts, which do not stop spending.
Supabase is open source and can be self-hosted. Firebase runs only on Google Cloud.

Supabase vs Firebase at a glance

	Supabase	Firebase
Database	Postgres	Firestore (documents), Realtime Database (JSON tree)
Queries	SQL with joins	Document queries, no joins
Access rules	Postgres row level security	Firebase security rules
Functions	Edge Functions on Deno (TypeScript)	Cloud Functions (Node.js, Python)
Offline sync	Not built in	Built into the Firestore SDKs
Push, crash reports, analytics	Not included	Cloud Messaging, Crashlytics, Analytics
Pricing model	Plan fee plus compute size	Pay per read, write, GB and invocation
Self-hosting	Yes, with Docker or the CLI	No

How do the data models differ?

Supabase: tables and SQL

A Supabase project is a full Postgres database. You define tables, foreign keys and indexes, and query them with SQL or through the API Supabase generates from your schema. A report that joins orders, customers and products is one query.

Postgres extensions come with it. pgvector stores embeddings next to the rows they describe, and PostGIS handles location queries.

Firebase: documents and collections

Firestore stores JSON-like documents in collections. Queries filter and sort within a collection, and there are no joins, so data that would be related in SQL is usually copied into each document that needs it. Updating a customer's name can mean writing to every order that holds a copy.

In exchange, Firestore's mobile and web SDKs cache data on the device, work offline and sync changes when the connection returns. Real-time listeners push updates to every client watching a document.

How does pricing compare?

The two bill in different units, so the cheaper one depends on traffic.

Firebase bills per operation

On Blaze, Firestore bills each document read, write and delete past a daily free quota.

Firestore location	Reads per 100K	Writes per 100K	Storage per GiB a month
Mumbai	$0.035	$0.104	$0.104
Frankfurt	$0.039	$0.117	$0.117

Every document a query returns is a read, so a list screen with 50 items costs 50 reads each time it opens. Firebase pricing explained covers Functions, Hosting and Storage line by line.

Supabase bills per plan and compute size

Pro is $25 a month per organization and includes $10 of compute credit, which covers one Micro project (1 GB of memory). Bigger sizes cost more: Small is about $15 a month and Medium about $60. Queries are not counted, so the bill follows the size the database needs. Supabase pricing explained has the full compute table.

Pro quota	Included	Past the quota
Database disk	8 GB per project	$0.125 per GB
Egress	250 GB	$0.09 per GB
Monthly active users	100,000	$0.00325 per user
File storage	100 GB	$0.0213 per GB
Edge Function invocations	2 million	$2 per million
Realtime messages	5 million	$2.50 per million
Realtime connections	500 concurrent	$10 per 1,000

Two example bills

A small app with 6 million Firestore reads, 900,000 writes and 2 GiB of data a month costs about $2 in Mumbai on Firebase. The same app on Supabase Pro is $25, or $0 on Supabase Free if it fits in 500 MB and stays active.

A busy app with 30 million reads, 3 million writes and 5 GiB costs about $12.90 a month in Mumbai on Firestore, with reads making up about three quarters of that. Supabase Pro stays at $25 while the database fits on Micro. Firebase is cheaper at low and moderate traffic. Its read charges grow in step with traffic, while a Supabase bill moves when you change the compute size.

How do the free plans compare?

	Supabase Free	Firebase Spark
Database	Postgres, 500 MB	Firestore, 1 GiB
Database limits	Two active projects	50,000 reads, 20,000 writes and 20,000 deletes a day
Egress	5 GB	10 GiB a month from Firestore
Auth	50,000 monthly active users	50,000 monthly active users
File storage	1 GB	Needs Blaze
Functions	500,000 Edge Function invocations	Needs Blaze
Realtime	200 concurrent connections, 2 million messages	Listener updates bill as reads
Inactivity	Project pauses after a week	No pause
Backups	None	None

Spark has no inactivity pause, which makes it the better home for a small app that gets little traffic. Supabase Free is the better fit when you need file storage or functions without a payment method.

Auth, storage and functions

Both include email, password and social sign-in, and both give 50,000 monthly active users on the free plan. On paid plans, Supabase Pro includes 100,000 and bills $0.00325 per user past that. Firebase bills past 50,000 at Google Cloud rates, and phone sign-in bills per SMS. Supabase's phone multi-factor authentication is a $75 a month add-on for the first project.

Supabase Storage is part of every plan, with 1 GB on Free and 100 GB on Pro. On Firebase, Cloud Storage needs Blaze, and its free amounts only apply to buckets in three US regions.

Supabase Edge Functions run TypeScript on Deno. Firebase Cloud Functions run Node.js or Python on Google Cloud, with 2 million invocations a month free on Blaze, then $0.40 per million plus CPU and memory time.

Spend limits and backups

Supabase Pro has a spend cap, on by default. With it on, usage past a quota stops until the next billing cycle. It covers disk, egress, users, storage, realtime and function invocations. Compute size and point-in-time recovery bill whether the cap is on or off.

Firebase has no spend cap. A Google Cloud budget sends alerts, and stopping the bill means disabling billing on the project or turning services off yourself.

Supabase Pro includes daily backups kept 7 days. Point-in-time recovery is $100 a month per 7 days of retention. Firestore backups and point-in-time recovery have no free usage and bill once enabled.

Regions

Supabase lets you pick a region per project, including Mumbai (ap-south-1), Frankfurt (eu-central-1) and London (eu-west-2). Firestore has locations in Mumbai (asia-south1) and Frankfurt (europe-west3), plus a Europe multi-region (eur3) that costs more. Put the database in the same region as most of your users.

Lock-in

Supabase is open source, and you can run it yourself with Docker. Because the database is Postgres, pg_dump moves the data to any Postgres host, and the SQL and row level security policies come with it.

Firebase runs only on Google Cloud. Moving off Firestore means exporting documents and redesigning them into another data model, and the client code that calls the Firebase SDK changes too.

Which should you pick?

Your app	Pick
Mobile app that must work offline	Firebase
Uses push notifications, Crashlytics and Analytics	Firebase
Relational data, reports or joins	Supabase
Vector search next to app data	Supabase, with pgvector
Small app with little traffic and no payment method	Firebase Spark
Wants a spend cap on usage	Supabase Pro
Wants to self-host later	Supabase

How Ownkube compares

Ownkube is a different shape from both. It runs your own backend, workers, scheduled jobs and a Postgres database, billed by the resources they use. It has no built-in auth, file storage or client SDK, so you bring a library for each. This fits a project that has outgrown calling the database straight from the frontend.

Postgres starts at $4 a month on a DB 0.5 box, plus $0.25 per GB of storage, and Postgres extensions such as pgvector and PostGIS turn on from the database settings. Compute bills at about $18 per vCPU a month and $6 per GiB, by the minute. Apps run in Mumbai or Germany.

Billing works from a prepaid wallet. Pay as you go starts with a $5 top-up, Personal is $5 a month and loads $5 of credit, and Team is $20 a month and loads $20. Credit never expires. When it runs out, apps pause and keep their data until you top up.

Checklist before you pick

Is your data relational, or does it fit in self-contained documents?
Does the app need to work offline on a phone?
How many documents does a busy screen read, and how often does it open?
Do you need a hard cap on usage, or are budget alerts enough?
Would you want to move the database to another host one day?

For other Postgres hosts, see Supabase alternatives, Neon vs Supabase and managed Postgres pricing.

FAQ

Is Supabase better than Firebase?

For relational data, SQL and a path to self-hosting, Supabase fits better. For a mobile app that needs offline sync, push notifications and crash reporting from one SDK, Firebase fits better.

Is Supabase cheaper than Firebase?

At low traffic, usually not: a small Firestore app often costs a few dollars a month on Blaze or nothing on Spark, while Supabase Pro starts at $25. Firestore bills every read, so a read-heavy app can cost more on Firebase once its traffic grows.

Can I migrate from Firebase to Supabase?

Yes. Firestore documents have to be mapped to tables, the security rules rewritten as row level security policies, and the client code moved from the Firebase SDK to the Supabase client. Firebase Auth users can be exported and imported.

Does Supabase have offline sync like Firebase?

Not built in. Supabase's client libraries query the database over the network. Apps that need offline sync add a separate library for it.

Can I self-host Firebase?

No. Firebase runs on Google Cloud only. The Firebase emulators run locally for development and testing.

Where Ownkube fits

If your app has its own API and uses Supabase or Firebase mostly as a database, Ownkube runs the API, its workers and Postgres together from a prepaid wallet. If you miss the dashboard's table editor, the Marketplace installs Directus (an admin studio and instant API) or NocoDB (a spreadsheet view), each with its own Postgres. Deploy my first app.

Railway vs Fly.io in 2026: pricing, regions and Postgres compared

Abhishek Jaiswal — Sun, 01 Nov 2026 13:36:52 +0000

Railway and Fly.io both run your containers without a cluster to manage, and they come at it from different directions. Railway is dashboard first: a project canvas, templates, and usage metered per second. Fly.io is infrastructure first: you run Machines, small VMs you size and place in the regions you choose, configured through fly.toml and the flyctl CLI.

This post compares how each prices, how they handle databases and idle apps, and which fits which kind of project. Prices were checked on 2026-10-13.

TL;DR

Railway bills usage at about $20 per vCPU and $10 per GB of memory a month. Hobby is $5 with $5 of usage included. It is the easier of the two to start with.
Fly.io bills each Machine by size while it runs, from $2.19 a month for shared-cpu-1x with 256 MB. Stopped Machines bill no CPU or memory. It is the stronger choice for apps that need to run close to users in several regions.
Postgres is the biggest price gap. Fly's Managed Postgres starts at $38 a month. Railway runs Postgres as a metered service, so a small database costs a few dollars.
For a small app with a database, Railway is cheaper. For a single tiny always-on app, Fly is cheaper.

How do Railway and Fly.io price?

	Railway	Fly.io
Billing model	Metered CPU and memory per second	Machine size per second while running
Plans	Free ($1 credit a month), Hobby $5, Pro $20	Pay as you go; support plans from $29
Smallest service	Whatever it uses, from cents	shared-cpu-1x 256 MB at $2.19 a month
Typical sizes	about $20 per vCPU, $10 per GB a month	512 MB $3.69, 1 GB $6.70, shared-cpu-2x 2 GB $13.39, performance-1x 2 GB $33
Idle apps	Optional Serverless sleep after 5 to 10 minutes without outbound traffic	Autostop stops or suspends Machines; stopped Machines bill only their root disk at $0.15 per GB
Volumes	about $0.15 per GB	$0.15 per GB
Egress	$0.05 per GB	$0.02 per GB in North America and Europe, $0.04 in Asia Pacific, $0.12 in Africa and India
Extras	Included	Dedicated IPv4 $2 a month

Fly's Machine prices also vary by region: a 1 GB Machine is $7.73 a month in Frankfurt and $8.50 in Singapore.

Which is cheaper, Railway or Fly.io?

Workload	Railway	Fly.io
Small always-on app (512 MB, 0.1 vCPU average)	about $7 on Hobby	$3.69
App + Postgres (app 0.25 vCPU / 0.5 GB, 5 GB database, 10 GB egress)	about $18.25	about $42 with Managed Postgres
A 24/7 Discord bot	inside the $5 Hobby plan	Fly's own example: $2.21

Fly wins on a single small Machine, because a fixed 512 MB size costs less than Railway's memory rate. Railway wins as soon as a managed database joins, because Fly's Managed Postgres starts at $38. You can run Postgres yourself on a Fly Machine with a volume for a few dollars, and then backups, failover and upgrades are yours.

Fly.io pricing explained and Railway pricing explained walk through each bill in detail.

How do regions compare?

Fly.io is built around placing Machines in many regions and routing each user to the nearest one through its Anycast network. Running the same app in three regions is a fly scale count command away, and a read replica of your database can sit next to each copy. Railway lets you choose a region per service and is the simpler model for an app that serves one market.

If your users are spread across continents and latency matters, Fly has the edge. If they are mostly in one region, the multi-region model is complexity you do not need.

How do the developer experiences compare?

Railway is configured in the dashboard: a canvas of services, one-click templates, variables shared across services, and preview environments per pull request. Most people deploy their first app without reading docs.

Fly.io is configured in fly.toml and driven by flyctl. You get fine control over Machines, volumes, health checks, and placement. Expect to read the docs and to run a few CLI commands for things the Railway dashboard does with a click.

Railway or Fly.io: which should you pick?

If you	Pick
Want the fastest path from repo to URL	Railway
Need an app and a managed Postgres on a small budget	Railway
Serve users on several continents	Fly.io
Run one tiny always-on process	Fly.io
Prefer configuration as code and a CLI	Fly.io

FAQ

Is Fly.io cheaper than Railway?

For a single small always-on app, yes: a 512 MB Machine is $3.69 a month, against about $7 of Railway usage for the same memory. With a managed database, Railway is cheaper, because Fly's Managed Postgres starts at $38 a month.

Does Fly.io have a free tier?

Fly.io is pay as you go. Small Machines cost a few dollars a month, and stopped Machines bill only their root disk storage.

Can Railway run in multiple regions like Fly.io?

Railway lets you pick a region for each service. Fly.io is designed around running copies of an app in many regions with Anycast routing to the nearest one, which suits globally distributed apps better.

Is it easy to move between Railway and Fly.io?

Both run containers from a Dockerfile, and Railway also builds without one. Moving means recreating services and variables, copying the database with pg_dump and pg_restore, and switching DNS.

Where Ownkube fits

Ownkube sits between the two on price and closer to Railway on experience.

CPU and memory are metered per minute at about $18 per vCPU and $6 per GiB a month, and managed Postgres runs on a flat box from $4 a month plus $0.25 per GB, with backups on the Personal and Team plans. The app + Postgres stack above comes to about $12.95 a month in the Germany region.

Usage draws a prepaid wallet, so the bill never runs past what you loaded, and credit never expires. See Fly.io alternatives for more options, or Go hosting for how a Go app runs on Ownkube. Deploy my first app.

Is Vercel free? What the Hobby plan covers in 2026

Abhishek Jaiswal — Sun, 01 Nov 2026 13:21:23 +0000

Yes, for personal projects. Vercel's Hobby plan costs $0, but it is for personal, non-commercial use only. Once anyone involved makes money from a project, including a freelancer paid to build it, Vercel expects it on Pro at $20 per developer seat a month. Hobby usage is also capped. You can't pay for more, and a project that hits a limit usually waits 30 days before that feature works again.

TL;DR

Hobby is $0 with one developer seat, for personal and non-commercial projects.
Ads, payments, affiliate sites and being paid to build or host the site all count as commercial. Asking for donations does not.
Each month includes 100 GB of transfer, 1M function invocations, 4 hours of active CPU and 360 GB-hours of function memory.
Past a limit you can't buy more usage, and in most cases the feature stays off for 30 days.
Cron jobs run at most once a day, a function run stops at 300 seconds, and runtime logs keep one hour.
Pro is $20 per developer seat a month with $20 of usage included. Vercel pricing explained works through Pro bills line by line.

What does the Vercel Hobby plan include?

Resource	Hobby allowance each month
Fast Data Transfer	100 GB
Fast Origin Transfer	10 GB
CDN requests	1M
Function invocations	1M
Active CPU	4 hours
Provisioned memory	360 GB-hours
Image transformations	5,000
Image cache reads	300K
Image cache writes	100K
Web Analytics events	50,000
Speed Insights events	10,000
Developer seats	1

Fast Data Transfer is what Vercel's CDN sends to visitors. For a blog or a portfolio it is the line that matters, and 100 GB is a lot of page views for a personal site.

The function lines start to count once the project has server code: API routes, server rendering and middleware. Active CPU only counts time the CPU is working. Provisioned memory counts the whole run, including time spent waiting on a database, so it tends to run out first.

What other limits does Hobby have?

Limit	Hobby	Pro
Projects	200	Unlimited
Function max duration	300 seconds	800 seconds (1,800 in beta)
Function memory and CPU	2 GB, 1 vCPU	Up to 4 GB, 2 vCPU
Build machine	2 vCPU, 8 GB	Larger machines available
Deployments per day	100	6,000
Domains per project	50	Unlimited
Runtime logs	1 hour	1 day
Team collaboration	No	Yes
Spend management	No	Yes
Password protection	No	$20 a month per project

Builds stop at 45 minutes on every plan.

Two of these limits bite first on real apps. The 300-second cap ends any single function run, so a long export, a slow report or a model call that streams past five minutes gets cut off. The one-hour log window means an error from last night is gone by the time you look in the morning.

Hobby is also one person. You can't add a teammate to a Hobby account, so the moment a second developer needs to deploy, the project moves to Pro.

What counts as commercial use on Vercel?

Vercel's fair use rules call a deployment commercial when it is used for the financial gain of anyone involved in any part of its production. That includes a paid employee or consultant who writes the code. Vercel's own examples:

the site asks visitors for payment or processes payments
the site advertises a product or service for sale
someone is paid to create, update or host the site
the site exists mainly to carry affiliate links
the site shows ads, such as Google AdSense

Asking for donations is allowed on Hobby.

The test looks at the people around the project as well as the site itself. A freelancer building a client's marketing page on Hobby is breaking the rule even if the page sells nothing, because the freelancer is paid for it. A personal portfolio or an open-source docs site with a donate button fits Hobby.

What happens when you hit a Hobby limit?

You can't buy extra usage on Hobby. When a project goes past an allowance, Vercel says that in most cases you have to wait 30 days before you can use that feature again. Web Analytics is the exception: collection resumes after 7 days.

That wait hurts most on a side project that suddenly gets traffic. The capped feature stays off until the 30 days pass or you move the project to Pro, where usage past the $20 credit bills pay as you go.

Can you run cron jobs and background work on Hobby?

Cron jobs work, with tight limits. A project can have 100 of them, and on Hobby each one runs at most once a day. Timing is per hour: a job set for 08:00 runs some time between 08:00 and 08:59. A more frequent schedule fails the deploy. Pro runs cron jobs down to once a minute.

Background work is the harder fit. Vercel runs server code as functions that start on a request and stop at the duration limit. A queue consumer, a Discord or Telegram bot that holds a connection open, or a job that runs for an hour needs to live on a host that keeps a process running.

Where do Hobby functions run?

New projects run functions in Washington, D.C. (iad1) by default. Hobby gets one function region, and you can change it in the project's settings or with regions in vercel.json. Mumbai (bom1) and Frankfurt (fra1) are both on the list.

That setting matters for anyone outside the US. A function in Washington that queries a database in Frankfurt or Mumbai pays the round trip on every query. Put the function region next to your database before you judge how fast the app feels.

When is the Hobby plan enough?

Project	Fits Hobby?
Personal blog or portfolio	Yes
Open-source docs site with a donate link	Yes
Hackathon entry or demo	Yes
Learning project with a nightly cron job	Yes
Side project that takes payments	No, it needs Pro
Site with ads or affiliate links	No, it needs Pro
Client site you are paid to build	No, it needs Pro
App with jobs longer than 300 seconds or a long-running worker	That part needs another host

When to stay on Vercel

If the project is a frontend that fits the Hobby rules, stay. Static pages, image optimization and Next.js features run well there, and moving a working site to save nothing makes little sense.

The same goes for a commercial frontend on Pro. For a team, $20 a seat is small next to the time it would take to run a CDN and preview deployments yourself. Ownkube has no CDN in front of the app and no per-branch preview deployments, so a frontend that leans on either belongs on Vercel.

What does the same backend cost on Ownkube?

Ownkube has no free plan for Compute. The smallest start is a $5 top-up on Pay as you go. Personal is $5 a month and loads $5 of credit, and Team is $20 a month and loads $20. Credit never expires.

A small API with Postgres, running around the clock in the Germany region:

Line	Monthly cost
App at 0.25 vCPU and 0.5 GiB	$6.75
Postgres on a DB 0.5 box	$4
5 GB of database storage	$1.25
50 GB of outbound transfer at $0.02 per GB	$1
Total	about $13

In the Mumbai region the same 50 GB of transfer bills at $0.13 per GB, so the total is about $18.50. You pick the region when you deploy.

The app is a long-running process, so it has no 300-second cap. Workers run continuously, and scheduled jobs take any cron expression with a time zone. If the app is idle for long stretches, sleep is opt-in: a sleeping app bills nothing for compute and a sleeping database bills storage only. When the wallet runs out, apps pause and keep their data until you top up, so the most a month can cost is what you loaded.

Backups are 7-day point-in-time restore on Personal and Team, turned on per database. Pay as you go has no backups.

Checklist before you pick a plan

Does anyone make money from this project, including the person building it? Then it needs Pro or another host.
Does any job run longer than 300 seconds or more often than once a day?
Is the function region next to the database?
Would a 30-day pause on a feature hurt your users?
Do you need logs older than one hour?
Will a second developer need to deploy?

If every answer is no, Hobby is a good home. If several are yes, price Pro with Vercel pricing explained, or compare hosts that run the backend and database together in Vercel alternatives.

FAQ

Is Vercel free forever?

The Hobby plan has no trial period. It stays $0 as long as the project is personal, non-commercial and inside the allowances.

Can I use Vercel Hobby for a client site?

No. Being paid to build, update or host a site counts as commercial use under Vercel's rules, even when the site itself sells nothing.

Can I show ads on a Vercel Hobby site?

No. Ads such as AdSense count as commercial use. Asking visitors for donations is allowed.

What happens if I exceed Vercel's free tier?

You can't buy more usage on Hobby. In most cases the feature you went over stays unavailable for 30 days, and Web Analytics resumes after 7. Upgrading to Pro lifts the caps.

Does Vercel have a Pro trial?

Yes. Vercel offers a Pro trial, and after it Pro is $20 per developer seat a month with $20 of usage included.

Can I host a backend on Vercel for free?

Short API calls, yes, within 1M invocations, 4 hours of active CPU and the 300-second limit per run. Workers, bots and long jobs need a host that keeps a process running. Free tiers on Railway, Render and Fly.io covers the other free options.

Where Ownkube fits

Keep a personal frontend on Vercel's Hobby plan if it fits. When the project turns commercial, needs a worker or a job that runs past five minutes, or needs its Postgres next to the app, Ownkube runs the whole backend in Mumbai or Germany from a prepaid wallet. Deploy my first app.

DEV Community: Abhishek Jaiswal

Where to host Uptime Kuma in 2026: five options, priced

Our picks

What Uptime Kuma needs from a host

The options at a glance

The options, one by one

Ownkube

Fly.io

Railway

Render

Your own VPS

Put the monitor somewhere else

When not to self-host Uptime Kuma

A quick checklist before you choose

FAQ

Can I run Uptime Kuma on Heroku?

Can Uptime Kuma run on a free tier?

How much memory does Uptime Kuma need?

What does Uptime Kuma cost on Ownkube?

Where Ownkube fits

Hosting that redeploys on every GitHub push: five low-maintenance options in 2026

Our picks

The five at a glance

What low maintenance actually takes

Builds without a Dockerfile

Rollouts that stop a bad build

Logs, metrics and alerts

Database backups

The options, one by one

Ownkube

Render

Railway

Heroku

Fly.io

A small backend, priced

Setting it up on Ownkube

When not to pick Ownkube

A quick checklist before you choose

FAQ

Which hosting platforms redeploy automatically from GitHub?

Can I stop a push from deploying on Ownkube?

What is the cheapest way to host a backend with a worker and a small database?

Where Ownkube fits

How to deploy a Ruby on Rails app on Ownkube

1. Prepare the app for production

2. Write a Dockerfile

3. Push the repo and create the app

4. Add a managed Postgres database

5. Set your secrets

6. Run migrations as a job

7. Scale and watch it run

Moving to your own AWS later

FAQ

Does Ownkube support Rails credentials and Active Storage?

Do I need a Dockerfile, or can Ownkube detect Rails automatically?

Can I run Sidekiq or another background worker alongside the web app?

What happens if my wallet balance runs out mid-month?

Can I roll back a bad deploy?

Where Ownkube fits

How to deploy a Next.js app on Ownkube

1. Enable standalone output

2. Write a Dockerfile

3. Push the repo and create the app

4. Set your environment variables

5. Add a managed Postgres database, if you use an ORM

6. Scale and watch it run

Moving to your own AWS later

FAQ

Do I need output: "standalone", or does the default build work?

Does Ownkube support the App Router and Server Actions?

How do I handle a value that is different between preview and production?

What happens if my wallet balance runs out mid-month?

Can I use a custom domain?

Should I host Next.js on Vercel instead?

Where Ownkube fits

How to deploy a FastAPI app on Ownkube

1. Structure the app for a container

2. Write a Dockerfile

3. Push the repo and create the app

4. Add a managed Postgres database, if you need one

Do I need `output: "standalone"`, or does the default build work?