Replit Deployment Guide: Static, Autoscale, Reserved VM, and Scheduled

Overview

Replit Deployments let you ship web apps, APIs, and background jobs directly from the browser-based IDE — no CI pipeline, no Docker config, no cloud console. You pick a deployment type, configure a run command, and click Deploy.

This guide covers all four deployment types, the .replit configuration that controls them, custom domain setup, secrets management, and the production gotchas that Replit’s own docs underplay. It’s written for developers who have a working Repl and want to get it running in production without surprises.

Prerequisites

Before deploying, make sure you have:

• A Replit account — Starter (free) works for Static deployments only
• A Replit Core ($25/mo) or higher plan for Autoscale, Reserved VM, or Scheduled deployments
• A working Repl that runs successfully in the workspace (click Run and verify it works before attempting deployment)
• A payment method on file if deploying anything beyond Static

For custom domains, you’ll also need access to your domain registrar’s DNS settings.

Choosing a Deployment Type

This is where most developers make their first mistake. Each type maps to a different GCP service under the hood, and choosing wrong means either overpaying or shipping broken UX.

Use Static for SPAs, portfolios, and landing pages with no backend. Use Autoscale for side projects and low-traffic APIs where cold starts are acceptable. Use Reserved VM for production apps, WebSocket servers, or anything where a 10–30 second cold start would lose users. Use Scheduled for cron jobs — scraping, notifications, report generation.

Step 1: Configure the .replit File

The .replit file is TOML-formatted and controls both development and production behavior. It’s hidden by default — enable “Show hidden files” in the filetree menu to see it.

entrypoint = "server.js"

[deployment]
run = ["node", "server.js"]
build = "npm install && npm run build"
deploymentTarget = "cloudrun"

The [deployment] section is what matters. Three properties:

• run — the command that starts your production server (string or array)
• build — runs once during deployment to install dependencies and compile
• deploymentTarget — "cloudrun" for Autoscale, "gce" for Reserved VM, "static" for Static

The development run command (top-level) can differ from [deployment].run. Use this to run dev servers with hot reload locally while deploying an optimized production build.

Step 2: Deploy Your App

Deployments are snapshot-based. Editing code in the workspace does NOT auto-update the live app. You must explicitly redeploy to push changes. This is intentional — it prevents broken WIP code from reaching production.

After deployment, use the Deployments tab to view logs, analytics, and trigger redeployments.

Building...
$ npm install && npm run build
✓ Build completed
Starting server...
$ node server.js
✓ Listening on 0.0.0.0:3000
✓ Health check passed
LIVE https://my-app.replit.app

Step 3: Set Up Secrets for Production

Replit separates workspace secrets from deployment secrets. This catches developers off guard — your app works in dev but crashes in production because the database URL isn’t set.

Workspace secrets live in Tools > Secrets. Deployment secrets are configured in the Deployments pane > Secrets section. You must add secrets to both places.

# Python
import os
db_url = os.environ['DATABASE_URL']

# Node.js
const dbUrl = process.env.DATABASE_URL;

Secrets are AES-256 encrypted at rest, hidden from the code editor, and excluded from forks and version history. Account-level secrets can be linked to multiple Repls — useful for shared credentials across microservices.

Step 4: Connect a Custom Domain

Custom domains require a paid plan and an active deployment.

If you use Cloudflare, set the DNS record to DNS-only mode (gray cloud icon). Cloudflare’s proxied mode breaks Replit’s automatic SSL certificate renewal. This is the single most common custom domain issue.

The Health Check That Blocks Every First Deploy

This is the gotcha that Replit’s troubleshooting docs mention but don’t emphasize enough: after deployment, Replit sends a GET / request to your app. If it doesn’t get a 200 response within 5 seconds, the deployment fails.

Two things break this constantly:

1. Binding to localhost. Your server must listen on 0.0.0.0, not 127.0.0.1 or localhost. Express defaults to 0.0.0.0, but some frameworks (like Flask with default settings) bind to localhost.

// Wrong — deployment health check will fail
app.listen(3000, 'localhost');

// Correct
app.listen(3000, '0.0.0.0');

2. Slow initialization. If your app loads ML models, connects to databases, or runs migrations on startup, the 5-second window closes before the server responds. Move heavy initialization to background tasks and return a lightweight 200 from / immediately.

# Flask example — respond fast, initialize later
@app.route('/')
def health():
    return 'OK', 200

# Run heavy setup in a background thread after server starts

Deployment Pricing Breakdown

Replit’s pricing has two layers: your plan subscription and per-deployment compute costs.

Reserved VM pricing scales by machine size: 0.5 vCPU / 1 GB RAM at ~$6/mo, 1 vCPU / 2 GB RAM at ~$15/mo, and 2 vCPU / 4 GB RAM at ~$50/mo.

The hidden cost is egress. Core plans include 100 GiB outbound data per month. Overages cost $0.10/GiB. A high-traffic API serving large payloads can generate significant bandwidth bills. Check the deployment pricing calculator before committing to Replit for anything bandwidth-heavy.

Using Replit Agent to Deploy

Replit Agent can handle the entire build-and-deploy flow from a natural language prompt. Describe what you want, and it writes the code, configures the .replit file, sets up secrets, and triggers deployment.

Agent 4 runs independent tasks in parallel — auth, database schema, backend routes, and frontend components build simultaneously. It also self-tests: executing code, identifying errors, fixing them, and rerunning until tests pass.

For deployment specifically, the Agent handles the .replit configuration and deployment settings automatically. You can also describe scheduled deployment timing in natural language (e.g., “run every weekday at 9 AM EST”) and the Agent converts it to a cron expression.

That said, Agent-generated deployments still hit the same health check and binding constraints. If the Agent’s deploy fails, check the same things you’d check manually: 0.0.0.0 binding, the 5-second health check window, and matching workspace vs. deployment secrets.

Tips and Best Practices

• Separate dev and prod run commands. Use the top-level run for hot-reload dev servers and [deployment].run for production. Don’t deploy with nodemon or flask --debug.
• Pin your Nix channel. The [nix] section in .replit controls system dependencies. Set channel = "stable-23_05" (or current stable) so deployments don’t break when Replit updates the default channel.
• Monitor egress early. If you’re serving images, large JSON responses, or file downloads, estimate your monthly bandwidth before choosing Replit over a traditional cloud provider. At $0.10/GiB overage, costs add up fast.
• Use Account Secrets for shared credentials. If you have multiple Repls connecting to the same database, store the connection string as an Account Secret rather than duplicating it across Repls.
• Restart after adding secrets. Secrets added while the app is running may not be picked up by the current process. Stop and re-run the Repl to reload environment variables.

When to Use Replit Deployments — and When Not To

Replit Deployments are excellent for prototypes, internal tools, side projects, and apps where deployment complexity is the main bottleneck. The zero-config approach from IDE to production URL is genuinely faster than setting up CI/CD on AWS, GCP, or Vercel for the first time.

Avoid Replit Deployments when you need fine-grained infrastructure control (custom Docker images, multi-region), predictable sub-100ms latency (Autoscale cold starts kill this), or high-bandwidth workloads where egress costs exceed what you’d pay on a VPS. For production SaaS with paying customers, evaluate whether the convenience is worth the limited observability and vendor lock-in compared to deploying on GCP directly (which is where Replit runs under the hood anyway).

FAQ