Skip to main content
These answers cover publishing and deployments. For step-by-step troubleshooting, see Troubleshooting deployments, and for deployment types and monitoring, see Autoscale deployments and Monitoring a deployment.
Most Autoscale publish failures are fixable once you read the deployment logs:
  1. Open Publishing and find the failed deployment.
  2. Select the three-dot menu next to it to open the logs.
  3. Copy the log output, open a new Agent chat, paste it, and ask what’s wrong and how to fix it.
If you see a No run command configured error even though you set one, open your deployment settings, disconnect the run command, re-add it, then save and republish. See Troubleshooting deployments.
If publishing succeeded but the live app returns a 500 error, the issue is in your app code rather than Replit’s infrastructure:
  1. Open Publishing, view the logs, and copy the full error text.
  2. Open a new Agent chat, paste the logs, and ask what’s causing the error.
  3. Apply the fix and republish.
If Agent can’t find the problem, open Publishing → History, find the last working version, and redeploy it. See Troubleshooting deployments.
  1. Open the Shell pane and run kill 1 to restart the background process. (kill 1 is safe in Replit—it restarts your project’s main process, it doesn’t delete anything.)
  2. Open Publishing and select Publish to trigger a new deployment.
  3. If it fails again, open the failed deployment’s logs from the three-dot menu, copy the build log, and paste it into a new Agent chat for diagnosis.
If the deployment stays stuck, contact Replit Support with your full build logs. See Troubleshooting deployments.
  1. Check your deployment logs for recurring timeout or out-of-memory messages.
  2. Check your deployment resources for CPU or memory limits—see Monitoring a deployment.
  3. Open a new Agent chat, paste recent logs, and ask Agent to find bottlenecks.
Common causes include database queries without indexes, blocking synchronous operations, and memory leaks. With Autoscale deployments, the first request after scaling to zero can take a few seconds—that’s a normal cold start.
Open Publishing → History, select the failed deployment, and view the build logs. Find the first line marked ERROR or FAILED—that’s usually the root cause, and the lines after it are knock-on effects. Copy that section into a new Agent chat for diagnosis. Most build failures come from missing dependencies, an incorrect run command, or a failed database migration. See Monitoring a deployment.
This is almost always a configuration difference between environments. Check that:
  • Every key from your development Secrets pane is also set in your deployment secrets—they’re separate environments.
  • Your DATABASE_URL points to the production database, not development.
  • There are no hard-coded localhost or 127.0.0.1 references; use relative paths or environment-based URLs instead.
Then check your deployment logs for production-specific errors. See Troubleshooting deployments.
Autoscale deployments restart regularly by design. A SIGTERM in your logs means the process was gracefully stopped—this is normal. Exit code 1 means the process crashed on its own; check the lines just before it for the actual error.If restarts are frequent enough to affect users, look for unhandled promise rejections, out-of-memory errors, or missing environment variables that cause startup to fail.
Replit keeps development and production secrets in separate stores, and changing one doesn’t update the other. The development Secrets pane is only available in the editor; your deployed app reads from your deployment secrets.To update a variable in your live app, set it in your deployment secrets, then open Publishing and select Publish to deploy again. The new values take effect when the new deployment starts. See Troubleshooting deployments.
Open Publishing and select Publish. Replit builds and deploys your current code even if nothing changed—useful after updating a secret, after a database unpause, or to pick up a dependency update.If your app is unresponsive and a full redeploy feels heavy, open the Shell pane and run kill 1 to restart the background process without redeploying.
Yes. Open Publishing, select a new region, and publish to redeploy there. See Publishing geography.Your database region can’t be changed in place—to move it, fork the app and deploy the forked version in the new region. After changing region, your .replit.app subdomain may change, so connect a custom domain first if you need a stable URL, and re-add any deployment secrets.
Open Publishing and select the option to shut down your deployment, then confirm. Your app goes offline and stops incurring deployment charges. Your project files, code, and database aren’t deleted—only the live deployment stops. Custom domain connections tied to this deployment are removed, so re-add them if you republish.If cost is your concern, note that Autoscale deployments scale to zero when there’s no traffic, so you may not need to shut down at all.

​
Still need help?

If your deployment question isn’t answered here, contact Replit Support.