Replit developer help · Replit Agent, Deployments, PostgreSQL
Fix your broken Replit app.
It works in the workspace and fails once published, uploads disappear, or the Agent keeps rewriting what worked. A senior engineer finds the cause and fixes it, keeping what works.
Photography is illustrative.
- Built with
- Replit Agent, in a cloud workspace
- Database
- PostgreSQL: a development database and a separate production database
- Hosting
- Replit Deployments: Autoscale, Reserved VM, Static or Scheduled
- Code
- Git pane: push to and pull from a GitHub repository
Who this is for
For founders whose Replit app works in the workspace and misbehaves in production.
Replit puts everything in one place: the workspace, the Agent that writes the code, the databases, sign-in, file storage and publishing. That is why it is quick to get something live, and why problems often appear only after you publish: the published app runs in a different environment from the workspace, with its own database, secrets and file system.
We work with that model rather than against it. We read the app as ordinary code, find which difference between workspace and production is biting, fix it, and decide with you whether the app stays on Replit, which for many apps is the right answer.
Failure modes
The ways Replit apps break.
These are what we look for first in a Replit Agent app. Most come from the gap between the workspace and the published app, and Replit's own documentation describes several of them.
-
Works in the workspace, fails when published
- What you see
- The app runs in the workspace, then publishing fails at the last step or the published app does not respond.
- What is actually wrong
- A published server must listen on
0.0.0.0;localhostdoes not work. Setting ports in.replitturns off automatic port detection, so the external port must be set to 80. Publishing can also fail if the home page takes more than five seconds to answer. - How we fix it
- Server and port configuration set correctly, a fast health route for the home page check, and a written publish checklist.
-
Secrets missing in the published app
- What you see
- Sign-in fails, payments break or the database will not connect, but only in the published app.
- What is actually wrong
- Secrets set in the workspace do not carry over to the published app; they have to be added again in the Publishing pane. Replit's own troubleshooting lists exactly these symptoms.
- How we fix it
- A list of every variable for each environment, and a start-up check that stops the app with a clear message when one is missing, instead of failing at the first customer.
-
Uploads that vanish
- What you see
- Profile pictures and uploaded files disappear after you publish again.
- What is actually wrong
- A published app's file system is not persistent: it resets on every publish. Files saved to disk are gone the next time you ship.
- How we fix it
- Uploads moved to Replit's App Storage or another object store, with the existing files recovered where they still exist.
-
Schema changes that break production at publish
- What you see
- You publish a new feature and the live app starts throwing database errors, or a column of real data is gone.
- What is actually wrong
- Replit gives you a development and a production database, and applies the development schema changes to production when you publish. Dropping a column or adding a required field without a default is a breaking change there, and the Agent cannot touch the production database to repair it.
- How we fix it
- Each change planned as a safe migration (add first, backfill, then remove), tried against a copy of production data before it ships.
-
Rollbacks that leave the data behind
- What you see
- You rolled back to a checkpoint and the app is still broken, or now broken differently.
- What is actually wrong
- A checkpoint rollback leaves the database alone unless you tick Database, and never restores the production database. Production has its own point-in-time restore, which in turn does not revert code.
- How we fix it
- A tested procedure that brings code and data back to the same point together, and backups we have actually restored from.
-
Signed in is not the same as allowed
- What you see
- Sign-in works, yet a user who changes an ID in the address bar sees someone else's record.
- What is actually wrong
- Replit Auth answers who the user is. Which records that user may read or change is the app's own code, and generated routes often check that someone is logged in without checking that the record is theirs.
- How we fix it
- An ownership check on every route that reads or changes data, enforced on the server, with a test for each one.
Before you hire anyone
What to try yourself first in Replit.
- Roll back to a checkpoint. The Agent makes checkpoints as it works. Roll back to the last good one, and tick Database only if you mean to roll back development data too.
- Check the published app's secrets. Open the Publishing pane and compare its secrets with the workspace's. A missing one explains most "works here, not there" failures.
- Check the address and port. Make sure the server listens on
0.0.0.0, and if.replitsets ports, that the external port is 80. - Read the deployment logs. Paste the exact error from the published app's logs into the Agent, rather than describing the symptom.
- Act fast on lost production data. Production databases have point-in-time restore: 7 days of history on Core and up to 28 days on Pro and Enterprise plans. Restore, roll back the matching checkpoint, then publish again.
- Keep a copy outside Replit. Connect a GitHub repository from the Git pane and push to it, so the code and its history exist somewhere you control.
How we work
How we work on a Replit app.
Replit hosts the code, the databases and the app together, but the code leaves easily: the Git pane pushes it to a GitHub repository and pulls changes back. We work through GitHub in branches, so you can keep using the Agent after we hand back.
Whether the app stays on Replit Deployments is a decision we make with you after the review. For many apps it is fine. Moving means taking the production database and secrets with it, and we say exactly what that involves before anyone commits to it.
-
A free 20-minute call
You show us the Replit app and tell us what is going wrong. We say what we expect to find, and whether a paid check is worth it yet.
-
Quick Security Check or App Readiness Review
A senior engineer reads the code and tests the running app: data access, keys, sign-in, payments, deployment.
You get Every finding in writing with its severity and fix; the review adds a keep, change or replace call for each part and a fixed quote.
-
Fixed-price fixes
Security & Data Hardening from $7,500, or Production Launch from $15,000, in your repository, with a test beside each fix.
-
Handover
Production kept apart from development, a deploy you can roll back, and notes so you, the tool or any developer can carry on.
Prices
Where to start, and what it costs.
-
App triage call
Free
20 minutes
-
Quick Security Check
$495
Delivered in 48 hours. The fee is credited toward the App Readiness Review.
-
App Readiness Review
$1,500 flat
5 business days. The fee is credited toward any fix booked within 30 days.
Fixes are priced after the check or review, at one fixed price before anything starts. The full price list and how fees are credited.
Proof
Who does the work.
A US software engineering firm. The founding team has taken a product off an AI app builder before (built, not yet in paid use) and runs a production telehealth platform on Supabase. We are an independent firm, not a Replit partner or agency. Across the systems the team built and runs:
- 20,900+ automated tests across the systems the founding team built and runs
- 16,800+ CI runs automated builds and test runs on GitHub Actions
- 940+ merged pull requests across the same codebases
Counted from the repositories and CI history of the systems the founding team built and runs, 22 Sep 2026; each figure rounded down. How we counted
Questions buyers ask
Replit questions, answered.
Should my app stay on Replit?
Often, yes. We look at your traffic, data and costs in the review and recommend staying or moving with the reason. If you move, the production PostgreSQL database and every secret move with it, and we plan that step by step.
Can I keep using Replit Agent after you fix it?
Yes. We work in the GitHub repository the workspace pushes to and pulls from, and add automated checks that every change, ours, yours or the Agent's, must pass before it is published.
Have I lost my data?
Maybe not. Replit keeps point-in-time history for production databases, 7 days on Core and up to 28 days on Pro and Enterprise. The sooner you restore, the more you get back.
Will you rewrite everything?
Rarely. The review marks each part keep, change or replace, with the reason, before any work is priced.
Are you affiliated with Replit?
No. Oracis is an independent US software engineering firm. We fix and finish apps built with Replit, alongside apps from Lovable, Bolt, Cursor and other tools.
What does it cost to fix a Replit app?
The first call is free. The Quick Security Check is $495 and its fee is credited toward the App Readiness Review, which is $1,500 flat and credited toward any fix booked within 30 days. Security & Data Hardening is from $7,500 and Production Launch from $15,000, each at one fixed price set after the review. We never bill hourly on work nobody has sized. The full price list.
Send us the Replit app.
The Replit link or the GitHub repository, what is going wrong, and when you need it fixed.