Replit Deployment Guide: Custom Domains, Secrets, Databases, and Monitoring

This is the tactical side of running a Replit app in production. If you are looking for the higher-level question of whether your Replit Agent build is actually ready to launch, start with Built with Replit Agent? Here's How to Ship It to Production. This guide assumes you are already focused on operations: deployment type, domains, secrets, persistence, and monitoring.

Replit's docs are useful here because they are explicit about how Publishing works: a published app is a snapshot of your project that runs separately from your workspace, on Replit's cloud infrastructure, with built-in support for domains, analytics, and monitoring. That is powerful, but it only works well if you choose the right model and understand the tradeoffs.

The important operational takeaway: deployment on Replit is not just clicking publish. It is deciding how your app should run, where state should live, how secrets should be managed, and how you will know when something is failing.

Replit Publishing: The Mental Model

Replit calls the deployment flow Publishing. According to the docs, a published app is a running instance of your app on Replit's cloud infrastructure, separate from the version in your workspace. Replit also states that published apps are hosted on Google Cloud Platform and in the United States.

- A publish creates a snapshot of files and dependencies
- The published app runs separately from the editor workspace
- Updating production means publishing again to create a fresh snapshot
- Replit explicitly advises against relying on the published filesystem for persistence

Which Deployment Type Should You Use?

Deployment type	Best for	What to know
Autoscale	Variable traffic web apps, APIs, and services	Replit says Autoscale can scale down when idle and supports custom domains and monitoring.
Reserved VM	Predictable, always-on workloads	Useful when you want a consistent amount of compute resources running continuously.
Static	Marketing sites and static frontends	Replit explicitly says Static Deployments are not compatible with Agent-generated apps.
Scheduled	Time-based jobs and automations	Best when the app is meant to run on a schedule instead of being continuously user-facing.

If the app came from Replit Agent and has a backend, start by evaluating Autoscale or Reserved VM. Static is a different category entirely.

Custom Domains

Replit supports custom domains on Autoscale, Reserved VM, and Static Deployments. The docs outline a simple flow: add the domain in Replit, copy the generated DNS records, enter them at your registrar, and wait for propagation.

What Replit says to do

- Add the custom domain in Publishing settings
- Copy the generated A and TXT record values
- Add those records at your registrar
- Wait for verification after propagation

Gotchas called out in the docs

- DNS propagation can take from minutes up to 48 hours
- Multiple A records pointing to different servers can break setup
- Replit notes that A and AAAA records should not coexist for the same domain
- Cloudflare proxied records can interfere with automatic certificate renewal

Secrets and Environment Variables

Replit's Secrets tool stores sensitive values as encrypted environment variables. The docs call out app-level and account-level secrets, and note that the data is encrypted at rest and in transit. This is the right place for API keys, auth tokens, and database credentials.

Useful details from the docs

- Secrets are available for all deployment types except Static Deployments
- Replit exposes predefined env vars like REPLIT_DOMAINS and REPLIT_DEPLOYMENT
- Database-related env vars may include DATABASE_URL, PGHOST, and related Postgres values

The operational mistake to avoid is mixing product secrets with ad hoc human memory. If only one person knows which value is set where, your deployment is fragile even if the app currently works.

Databases, Storage, and Persistence

Replit's docs say two important things here. First, Replit provides storage covering databases and object storage. Second, published app filesystems should not be treated as persistent storage. That means deployment planning has to start with the question, "Where does the product's durable state live?"

A simple rule

If losing the data would be a real problem, do not leave it on the published app filesystem. Put it in a database or storage layer designed for persistence, backup, and operational access.

Monitoring and Analytics

Replit's Published App Monitoring docs are more complete than many teams realize. Depending on deployment type, Publishing can show overview status, logs, resource usage, and analytics. Replit also says logs are retained for 7 days.

Monitoring views

- Overview: status, domain, deployment type
- Logs: searchable logs with date filtering
- Resources: CPU and memory utilization
- Manage: domains, deployment settings, and shut down controls

Analytics available in docs

- Page views
- Top URLs and top referrers
- HTTP statuses and request durations
- Browser, device, and country breakdowns

That said, built-in visibility is only useful if someone is actually reviewing it. For customer-facing products, many teams eventually layer in external error tracking, incident workflows, or more explicit alerting.

Common Replit Deployment Mistakes

Using Static for an Agent-built app

Replit's docs explicitly say Agent-generated apps need a backend server, so Static is the wrong fit for that class of project.

Treating the filesystem like a database

Replit warns against relying on the published filesystem for persistence. Teams still make this mistake when they move too quickly.

Hardcoding credentials instead of using Secrets

Even if the app works during testing, secrets hygiene becomes painful fast once environments, teammates, or third-party services multiply.

Skipping monitoring until after launch

Production issues are much harder to untangle when the first time you open the logs is after users are already complaining.

Stay on Replit or Move Beyond It?

There is no universal answer. Some teams should absolutely stay on Replit longer. Others hit a point where they need more control over environments, release process, data model, or security review. If you are still deciding, read our Replit Agent production guide for the broader decision framework.

Frequently Asked Questions

What deployment types does Replit offer?

Replit Publishing offers Autoscale, Static, Reserved VM, and Scheduled deployments. The right choice depends on whether your app is dynamic, always-on, or time-based. Replit also notes that Agent-generated apps are not compatible with Static Deployments.

Can I use a custom domain on Replit?

Yes. Replit supports custom domains for Autoscale, Reserved VM, and Static deployments. You add the domain in Replit, copy the generated DNS records, and wait for propagation, which Replit says can take from a few minutes up to 48 hours.

How should I handle secrets in Replit?

Use the Secrets tool so credentials are stored as encrypted environment variables instead of being hardcoded in the codebase. Replit supports app-level and account-level secrets, and the docs note that Secrets are available for all deployment types except Static Deployments.

Is the published app filesystem persistent?

No. Replit's Publishing documentation explicitly says you should avoid saving and relying on data written to a published app's filesystem. Durable data should live in a database or storage service.

What monitoring does Replit provide out of the box?

Replit provides overview status, logs, resource usage, and analytics in the Publishing interface. Logs are retained for 7 days, and analytics can include page views, top URLs, referrers, response codes, request durations, and device and country breakdowns depending on deployment type.