Publishing guide / Replit for business
How to publish a Replit web app
A working preview is not the same as a release for customers. Before publishing, decide how the app should run, what data and credentials it needs, who may access it and who will own it after launch.
Use Replit's development preview to check work in progress, then create a deployment through the Publishing tool when you are ready to share a stable version. Choose Static for a site made only of files, Autoscale for request-driven web workloads that can scale with demand, or Reserved VM when continuous, dedicated resources suit the workload. Configure production secrets and data deliberately, set access and domain options, test the published URL, and assign an owner for costs, changes and incidents. Publishing a web app does not submit a mobile app to either app store.
1. Treat preview and deployment as different stages
A preview helps the team inspect a development version. A published deployment is the version intended to remain available to users, so treat it as a release rather than as another preview link.
Use preview to review, not to promise availability
Try the main screens and workflows in the development preview, including forms, navigation and error states. Development URLs are for working on and testing a project; they are not a substitute for setting up a published app with a stable URL. Preview success alone does not show that production settings, traffic handling or access controls are correct.
Publish a release deliberately
Use the Publishing tool to create the web deployment, then check the resulting published URL as a user would. Replit's publishing documentation describes republishing changes to update the live version. Agree who can make that change and how the team will review it, particularly if users depend on the app.
Keep web and mobile distribution separate
Publishing a web app makes a web version available at its deployment URL. It does not automatically package or submit an app to the Apple App Store or Google Play. Replit documents a separate native mobile build and launch workflow; consult the current mobile guides for the route, supported platforms and store requirements before planning a mobile release.
2. Match the deployment type to the workload and cost model
Choose based on what the application does and when it must run, not simply on the most powerful-looking option. Deployment behaviour and billing differ, and the right choice depends on actual usage.
Use Static for file-based sites
Static deployment serves files and is appropriate when the site does not need a running server to handle requests or perform backend work. A site that relies on server routes, database access or application-side processing needs a suitable backend deployment instead. Check that the deployed site still works for its intended navigation and assets.
Compare Autoscale with Reserved VM
Autoscale is intended for workloads that respond to requests and can adjust resources with demand. Reserved VM provides continuously allocated resources and may suit a service that needs them to remain available. Compare expected traffic, response needs, resource settings and billing before choosing; neither option guarantees a particular level of performance or availability.
Estimate spend from usage, then monitor it
Publishing charges can depend on deployment type and consumption, including compute, requests or outbound data transfer; production database use can add separate costs. Estimate using the current pricing documentation and your likely traffic rather than assuming a fixed total. Set suitable resource limits where available, monitor account usage and review actual costs after launch. Prices and included credits can change.
3. Prepare production configuration, data and access
The published app is an operational environment with its own configuration. Do not assume that development credentials, records or access choices automatically create the production setup your business needs.
Set deployment secrets separately
Keep API keys, passwords and other credentials out of source code. Replit's documentation distinguishes project Secrets from deployment secrets: add and verify the values required by the published app in its deployment configuration. Check that missing or invalid values produce a controlled error, and rotate credentials if they have been exposed.
Check the production database and its data
Replit documents separate development and production database environments for published apps. Identify which database the live app will use, understand how required schema changes reach production, and decide how any business data is created or transferred. Test with non-sensitive records first and confirm the application's validation, access rules and recovery arrangements. Do not assume a development dataset has been copied into production.
Choose an access policy and configure the domain
Set the deployment's visibility to match the audience, such as public, password-protected or an available private access option. A deployment-level gate controls who can open the app; it does not replace sign-in and server-side authorisation for individual records or actions. If using a custom domain, configure it for the published app and test the domain and any required redirects.
4. Smoke-test the published app and assign an owner
A successful publish is a useful checkpoint, not proof that the application is secure, compliant or ready for every production requirement. Verify the real release and make ongoing responsibilities explicit.
Run a short test on the live URL
From a browser or device outside the development session, check the published URL, domain, sign-in and intended access restrictions. Exercise a representative end-to-end task, including saving and retrieving data, and check important error paths. Confirm that required production integrations work without exposing secrets. Record issues and retest after changes.
Name the people responsible for operating it
Assign an owner for deployment changes, access reviews, dependency and security updates, user support, incident response and cost monitoring. Decide how the team will detect problems, communicate an interruption and restore service or data where possible. Replit's shared-responsibility guidance makes clear that platform services do not remove the app owner's responsibilities for application configuration and behaviour.
Set expectations for the release
Document what the app is for, its audience, known limitations, data handling and the route for reporting a problem. Obtain the security, privacy, legal and operational reviews that apply to your organisation. A smoke test is only a basic check; it is not a substitute for a risk assessment, load testing, formal assurance or a service-level commitment.
Questions people ask
Is a Replit preview the same as publishing?
No. A preview is useful while developing and reviewing a project. Publishing creates a deployment intended to be shared at a stable URL, with its own production configuration and operational considerations. Test the published version rather than relying only on the preview.
Which deployment type should a business choose?
It depends on the workload. Static is for sites served as files without backend processing; Autoscale and Reserved VM suit different server workloads and resource patterns. Compare the current deployment documentation, expected traffic, availability needs and costs, then test the selected configuration.
Does publishing a web app put it in the Apple App Store or Google Play?
No. A Replit web deployment is not an app-store submission. Replit documents a separate native mobile build and launch route. Check the current mobile documentation for platform availability and submission requirements; publishing the web app alone does not complete those steps.
Sources and scope
This is independent editorial guidance for business buyers, not official Replit advice, a security or compliance assessment, or a guarantee of production readiness. Deployment features, mobile publishing routes and prices can change. Verify current documentation and your own requirements before release. Last reviewed 28 September 2026.
Replit documentation consulted
Planning a business release?
Discuss your users, data, access requirements and operational constraints before choosing a deployment. An independent review can help identify questions to resolve, but it is not a guarantee of a production outcome.
Discuss your project