Replit Tightened Core and Pro: When to Move Off Replit Deployments to Your Own Kubernetes Cluster

Key points:

• What changed in late October 2026: Replit removed Plan mode from Core and removed the 10 parallel agents and the 50 viewer invites from Pro, with prices unchanged at $20 and $100 a month (PricingSaaS change log for Replit, Replit pricing). The change hits the building side. Replit Deployments pricing did not go up, and dropped on 1 August 2026 (Replit docs).
• So a plan change alone is not a reason to migrate. Move a published app off Replit Deployments when production requirements push you out: data must live in your own cloud account, a customer asks for audit evidence, you need more than one service plus workers and queues, the production database approaches the 100 GiB limit, or engineers now own the code in GitHub.
• Stay on Replit when the app is an internal tool, a prototype or a low-traffic product built by non-engineers. Autoscale scales to zero and costs little at that size. Replit Enterprise also offers BYOC and Image Exports (Docker image plus Terraform) in early access, which is the shortest path if you already buy Enterprise (Replit BYOC docs).
• The migration has six parts: code to Git, a Dockerfile, the production PostgreSQL (pg_dump -Fc from the production DATABASE_URL), App Storage files, Replit Auth users, and the deployment types mapped to Kubernetes objects. Auth is usually the slowest part.
• You do not need a Kubernetes team to land on Kubernetes. Qovery deploys the app, workers, cron jobs and a managed PostgreSQL into your own AWS, GCP, Azure or Scaleway account, or an existing cluster, with git-push deployments and a preview environment per pull request. Coding agents can drive it through Qovery Agent Skills.

Replit changed its Core and Pro plans again at the end of October, and my inbox filled with the same question: "Is this the moment to get our app off Replit?"

My honest answer: maybe, but not because of the plan change. The late-October cuts touched Replit Agent features. They did not touch what you pay to keep a published app running. The question to ask is whether your app has outgrown the place it was born. I have interviewed more than 200 CTOs, and the tool that got them to their first customers was rarely the tool their tenth enterprise customer accepted.

All facts were checked on 14 November 2026 against Replit's own pricing page and docs.

What exactly did Replit change in Core and Pro in late October 2026?

Replit removed Plan mode from Core, and removed "10 parallel agents" and "Invite up to 50 viewers" from Pro, during the week of 26 October 2026, with list prices unchanged. PricingSaaS, which snapshots the pricing page daily, recorded the change on 1 November 2026 (PricingSaaS).

It is the latest step in a year of repackaging. The same change log shows Core losing its explicit "2 parallel agents" line in early September, the free Starter plan disappearing from the pricing page on 11 September, and Core's monthly credit allocation moving between $20 and $25 during 2026 (PricingSaaS).

The plans as they stand today, from Replit's pricing page:

Publishing costs are billed separately from the plan, drawn from your monthly credits and then usage-based (Replit docs: publishing costs). And those prices went down. On 1 August 2026, Autoscale compute dropped from $3.20 to $0.60 per million compute units, and requests from $1.20 to $0.40 per million (Replit docs: Aug 2026 pricing updates).

If you are angry about losing parallel agents, rethink where you build, and keep that decision separate from where you run.

When does it make sense to move off Replit Deployments, and when should you stay?

Move a published Replit app to your own Kubernetes cluster when at least two of these seven signals are true: data must live in your cloud account, an auditor or customer needs evidence you cannot produce, the app has become several services, the database is heading for 100 GiB, steady traffic makes per-request billing expensive, engineers own the code in Git, or agents need governed access to production. With none of them, stay.

The seven signals, in the order I see them in practice:

1. Data residency in your own account. Replit lets you pick a publishing geography (North America, Europe, Asia, South America, Australia), but the infrastructure is Replit's, and the geography cannot be changed after publishing (Replit docs: geography). An enterprise contract that says "in our AWS account, in eu-west-3, inside our VPC" needs something else.
2. Audit evidence. Security questionnaires ask who deployed what, when, with which approval, and where the logs live. On Kubernetes in your account, you own the cloud audit trail, the cluster audit log and your CI history.
3. More than one service. Agent-built apps start as one full-stack process. Growth adds a queue worker, a webhook receiver, a cron job, a second API. Replit models these as separate deployment types; Kubernetes models them as one environment.
4. Database size and control. Each Replit production PostgreSQL database is limited to 100 GiB on paid plans (Replit docs: database billing). You also cannot pick extensions, replicas or maintenance windows the way you can on Amazon RDS, Cloud SQL or Azure Database for PostgreSQL.
5. Steady traffic. Autoscale bills compute units while requests are served: 18 compute units per CPU-second and 2 per GB-second of memory (Replit docs). For spiky, low traffic that is great. For a busy API that never sleeps, a fixed node you already pay for, often under committed spend or credits, wins.
6. Engineers own the code. Once the app lives in GitHub or GitLab with pull requests, code review and CI, a platform that deploys from Git and spins up a preview environment per pull request fits the workflow better than publishing from a workspace.
7. Agents touching production. Replit already restricts its Agent to a read replica of production (Replit docs: development and production databases). When Claude Code, Cursor or Codex start deploying, you want scoped tokens, policies and an audit log on your side.

Stay on Replit when the app is an internal tool, a demo, a landing page with a form, or a product with a few hundred users built by people who do not want to think about infrastructure. Replit is very good at that job, and a Kubernetes cluster has a fixed cost floor (see below) that a small app does not justify.

A fair note on the third column. Replit's BYOC documentation describes three options for enterprises: Full BYOC (private preview), BYOC for Published Apps (early access), and Image Exports (early access), where "Publish" produces a Docker image, a Terraform file and an SBOM that your team deploys and operates. If you already pay for Replit Enterprise, ask for Image Exports first. It is the shortest path out.

What does it really cost to run the same app on your own Kubernetes cluster?

A Kubernetes cluster has a fixed floor before your first pod: Amazon EKS charges $0.10 per cluster per hour for the control plane, about $73 a month, plus the worker nodes (AWS EKS pricing). Moving one small app off Replit rarely saves money. The economics work when several apps share one cluster, or when cloud credits and committed spend already cover the nodes.

Compare that with what Replit charges for an always-on server today (Replit docs: publishing costs):

Add the production database: compute time at $0.16 per compute hour, where a database counts as active while it receives requests and for 5 minutes after the last one, and storage at $0.35 per GiB per month after the August price cut (Replit docs).

Three conclusions:

• One app, modest traffic: Replit is usually cheaper than a dedicated cluster. Do not migrate for cost alone.
• Five apps, or one busy app with workers: the cluster floor amortises, and you pay your cloud provider's rates, including Savings Plans, committed use discounts and startup credits.
• The hidden cost is people. A DIY cluster needs someone to upgrade Kubernetes, patch nodes, run ingress, certificates, autoscaling and observability. That is the cost Qovery removes, and the reason to compare "DIY" and "managed" as separate columns.

Cluster versions age out. On EKS, a version past its 14-month standard support window moves to extended support at $0.60 per cluster per hour (AWS EKS pricing). Whoever runs your cluster must keep upgrading it.

What do you have to replace when you leave Replit Deployments?

You replace six things: the source of truth for code, the runtime, the production PostgreSQL, App Storage, Replit Auth, and the deployment types themselves. Write all six down before you start. The teams that stall are the ones who migrated the code and discovered on cutover day that their users sign in with Replit accounts.

Sources: deployment types, storage and databases, Replit Auth.

One code smell to hunt for: checks on REPLIT_DEPLOYMENT. Replit sets REPLIT_DEPLOYMENT=1 in published apps (Replit docs), and agent-written code sometimes branches on it to decide "am I in production?". Replace it with your own APP_ENV variable before you move anything.

How do you migrate a Replit app to Kubernetes, step by step?

Run the migration in six steps, in this order: Git, container, database, files, auth, cutover. Each step is testable on its own, and only the last one touches live users. A typical agent-built app with one service and one database moves in a few days of focused work. Auth decides the long tail.

Step 1: Get the code into Git

Connect the project to GitHub or GitLab from the Git pane and push the main branch (Replit docs: Git pane). From now on, the repository is the source of truth, not the workspace.

Check three files before moving on: .replit (your run and build commands), the lockfile for your language, and any replit.nix or system packages the app depends on. Those become your Dockerfile.

Step 2: Write a Dockerfile

Translate the run command from .replit into a container. Two rules carry most of the work: listen on 0.0.0.0, and read the port from the PORT environment variable rather than hardcoding it.

FROM node:22-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-slim
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app ./
EXPOSE 8080
CMD ["npm", "run", "start"]

Run it locally with docker run -e PORT=8080 -e DATABASE_URL=... -p 8080:8080. If it works on your laptop against a copy of the database, it will work on Kubernetes.

Step 3: Move the production PostgreSQL

Dump the production database with pg_dump in custom format and restore it into a managed PostgreSQL in your account. pg_dump "makes consistent exports even if the database is being used concurrently" and does not block readers or writers, and the custom format is compressed and restorable item by item with pg_restore (PostgreSQL docs).

Be careful which URL you use. Both Replit databases use a variable called DATABASE_URL, but in the workspace and Shell it points to the development database, and only the published app gets the production one (Replit docs). Copy the production connection string from the Database tool, not from your Shell.

pg_dump "$REPLIT_PROD_DATABASE_URL" -Fc --no-owner --no-acl -f replit-prod.dump

# Restore into the managed PostgreSQL in your cloud account
pg_restore --no-owner --no-acl -d "$NEW_DATABASE_URL" replit-prod.dump

# Sanity check: compare row counts per table on both sides
psql "$NEW_DATABASE_URL" -c "SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY relname;"

Two details from Replit's docs:

• Publishing applies schema with drizzle-kit, and it does not copy functions, procedures, triggers, domains or grants to production (Replit docs). If your app relies on objects created by hand, check that they exist in the dump.
• Pick a target version at least as new as the source and run ANALYZE after the restore so the planner has fresh statistics.

Match the managed database to your cloud: Amazon RDS or Aurora on AWS, Cloud SQL on GCP, Azure Database for PostgreSQL on Azure, Scaleway Managed Database on Scaleway.

Step 4: Move App Storage files

Replit App Storage is backed by Google Cloud Storage and supports the Replit SDKs and GCS client libraries (Replit docs). Write a one-off script with the App Storage SDK that lists every object and uploads it to your bucket, keeping the same object keys so stored URLs and database references still resolve.

Then swap the client in your code from the Replit SDK to your provider's SDK (S3, GCS, Azure Blob). If your files are already on GCS and you land on GCP, this step is mostly a copy.

Step 5: Move users off Replit Auth

Replit Auth lets users sign in with their Replit accounts, with zero setup (Replit docs). That convenience is the strongest lock-in in the whole stack, because your user table is keyed to identities Replit issues.

Do this step while you are still on Replit. Replit documents a path to move an existing Replit Auth app to Clerk Auth while preserving user data (Replit docs: migrate to Clerk). Once users sign in through an identity provider you control (Clerk, Auth0, WorkOS, Keycloak or your own), the app is portable. If you skip it, every user has to sign up again on cutover day.

Step 6: Deploy on Kubernetes and cut over

Map each Replit deployment type to its Kubernetes object, deploy to a staging environment, then cut over DNS.

• Autoscale becomes a Deployment plus a HorizontalPodAutoscaler. The HPA scales pods on CPU, memory or custom metrics (Kubernetes docs). It does not scale to zero by default, so a quiet app keeps at least one replica.
• Reserved VM background workers become Deployments with no Service.
• Scheduled Deployments become CronJobs. Set concurrencyPolicy: Forbid unless overlapping runs are safe, because the default allows them (Kubernetes docs).

The cutover runbook I use:

1. Lower the DNS TTL on your custom domain to 60 seconds, 48 hours ahead.
2. Run the full stack on Kubernetes against a restored copy of production for a few days. Fix what breaks.
3. Announce a short write freeze. Put the Replit app in maintenance mode.
4. Take a final pg_dump, restore, compare row counts, sync any new App Storage objects.
5. Point DNS at the new ingress. Watch error rates and logs for an hour.
6. Keep the Replit deployment and its database for a week as a rollback path, then shut them down.

Where should the new stack run, and do you need a Kubernetes team for it?

Run it in your own cloud account, on the cloud your company already buys from: AWS, GCP, Azure or Scaleway, or an existing cluster your company runs. You do not need a Kubernetes team if a platform operates the cluster for you, and that is the gap Qovery fills.

Qovery is an Agentic DevOps platform: the control plane is ours, and the data plane, meaning your cluster, your apps and your data, stays in your cloud account. Qovery never hosts your app. Concretely, after the migration you get:

• Git-push deployments from GitHub, GitLab or Bitbucket, with the Dockerfile from step 2.
• A preview environment per pull request, cloned from your environment, so every agent-written change gets a full-stack URL before it merges.
• Managed databases in your account, for example Amazon RDS through Blueprints, or a container database for previews.
• Services, workers and cron jobs in one environment, plus Helm charts and Terraform or OpenTofu services when you need them.
• RBAC, audit logs and OPA-based policy tokens that scope what an agent can do (Qovery blog: OPA).
• Bring your own cluster: if you already run EKS, GKE, AKS, Kapsule, k3s or an on-premise cluster on Kubernetes 1.31 or later, install the Qovery agent on it instead of creating a new one (Qovery docs).

The Free plan covers 3 users, unlimited AI agents and one cluster of your own, which is enough to run the whole migration on a staging cluster before you commit.

If you want a broader view of the options before choosing, I compared Railway, Render and your own cloud account for scaleups, and wrote about why Lovable, Bolt and Replit apps worry CISOs. For a database-heavy migration, the same phased approach appears in our guide to moving off Convex to Postgres on Kubernetes.

How do I run this migration with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, and your coding agent can write the Dockerfile, provision the database and deploy the app into your own cloud account while you approve each step. The Qovery MCP Server operates what already exists and is read-only by default.

1. Install the skills globally for Claude Code, Cursor, Codex, OpenCode and Gemini CLI. The script asks before it writes anything to your machine.

curl -fsSL https://skill.qovery.com/install.sh | bash

1. Or scope them to the repository you just exported from Replit:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

1. Add the Qovery MCP Server to Claude Code. It opens an OAuth login in your browser and is read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

1. Only if you want the agent to change things through MCP, add the write-enabled server. This also requires turning on write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills include qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. Then ask in plain language: "This app came from Replit. Write a Dockerfile, deploy it with a managed PostgreSQL to my AWS account with Qovery, and create a preview environment per pull request." The agent asks you to approve every action. Swap AWS for GCP, Azure, Scaleway or your existing cluster; nothing in these commands is AWS-specific.

Run the database dump and the Replit Auth migration yourself. Those two steps touch real user data, and I want a human holding them.

Start with the AI agent quickstart or the Claude Code integration.