← All guides

Replit deployment rescue

Replit app works in the editor but not in production

ReplitVPSDomain

Short answer

The same Replit app running on a live server with HTTPS, backups, and a deployment path you can repeat.

Why this matters

The app runs in Replit, but the exported or migrated version fails when it has to live on a real host with real traffic.

Walkthrough

  1. 01

    Export and document the app

    Get the code out of the Replit editor and write down what the app needs to run outside that environment. Replit provides a managed runtime that includes system dependencies, environment injection, and port proxying automatically. None of that exists on a plain server.

    • Move the project into a GitHub repo using Replit's git integration or download and push manually to preserve commit history.
    • List the build and start commands from the Replit configuration panel or .replit file. These are the exact commands the server needs to run.
    • Document every environment variable the app reads, every external service URL, and every API key. Replit's Secrets tab stores these but does not export them.
    • Check the Replit shell or configuration for any system dependencies the app installed via apt or that come pre-installed on Replit's runtime.
    • Identify the port the app binds to and note whether Replit proxied it automatically or the app explicitly listened on a port.
  2. 02

    Mirror the runtime on production

    The editor was masking missing configuration. Your server needs everything explicit: the Node version, the build step, the start command, and every environment variable. A Replit app that ran for weeks in the editor can fail within seconds on a bare server.

    • Set production environment variables on the server. Replit Secrets do not transfer automatically, so add each one manually to the deploy panel or .env file.
    • Update the domain, auth callback URLs, CORS origins, and webhook URLs from the Replit preview domain to your production domain.
    • Run the app under a process manager (PM2, systemd, or Docker) that keeps it alive. Replit handled this invisibly; a VPS will not.
    • Install the correct Node or Python version on the server. Replit may have used a version different from what the server defaults to.
    • Open the required port in the server firewall and configure a reverse proxy (Nginx or Caddy) to serve the app on port 80/443 with HTTPS.
  3. 03

    Deploy, test, and keep the savings

    The goal is not just a live URL. It is an app you own with predictable monthly cost. Replit hosting starts free but scales with usage. A fixed-price VPS replaces that variable cost with a predictable monthly bill.

    • Smoke test every important flow on the live domain: user signup, login, data submission, file upload, and payment checkout.
    • Set up automated daily backups of the server and database before launch. Test the restore procedure to confirm backups actually work.
    • Compare the Replit subscription cost against the VPS monthly price. The savings typically cover the deploy service fee within 2-3 months.
    • Create a simple runbook with SSH login, restart, log viewing, and deploy commands so anyone on the team can manage the server.
    • Monitor the app for the first week after migration to catch any Replit-specific APIs or services that do not have equivalents on a standard Linux server.

Where RepoAssistant fits

RepoAssistant moves Replit apps to production so you own the server, the domain, and the bill.