Publish and Operate the App
Release a secure app on the right publishing model, connect its domain, watch its health and cost, and respond when reality changes.
By the end
A production release with verified configuration, domain, smoke tests, monitoring, security review, cost boundaries, incident ownership, and a safe rollback plan.
Build a release candidate
A release candidate is a named version you believe may be ready for production. Freeze its intended scope, review its checkpoint and Git diff, run the quality suite, verify migrations, inspect the Security Center, and list unresolved risks. Publish that version, not an unnamed pile of the latest edits.
Create a go/no-go gate. A blocker is anything that threatens access control, data integrity, the critical journey, recovery, or an agreed cost boundary. A cosmetic imperfection can be recorded and deferred. Clear criteria keep launch pressure from redefining readiness at the last minute.
Choose publishing by workload
Match the publishing type to the app. Static publishing suits content that does not need a continuously running server. Autoscale suits request-driven web apps and APIs with variable traffic. A reserved VM suits steady or always-on workloads requiring dedicated resources. Scheduled publishing suits timed jobs rather than interactive websites. Current availability, limits, and pricing can change, so confirm the live Replit docs before launch.
Choose with a workload estimate: expected requests, concurrency, response time, memory, CPU, background work, and idle periods. A technically valid deployment can still be operationally wrong if a background worker sleeps, a static site expects server secrets, or an always-on VM exceeds the budget.
Configure production explicitly
Production has its own database, secrets, callback URLs, allowed origins, build command, start command, and domains. Create an environment matrix and verify presence without exposing values. Apply production migrations deliberately and record their result. Use a separate test or staging destination for consequential integrations until the final go gate.
Connect a custom domain through the Publishing tools and wait for verification. Test both the platform URL and custom domain when they matter, including HTTPS, redirects, authentication callbacks, and canonical links. Domain success does not prove the application behind it is the expected release; record the release identifier too.
Monitor user health and system health
Published App Monitoring can expose status, logs, resources, analytics, response durations, HTTP status patterns, and uptime, depending on publishing type and plan. These help answer whether the service is reachable and how it behaves. Add an application-level health check that verifies essential internal dependencies safely without returning secrets or sensitive data.
Pair technical signals with workflow signals: submissions started and completed, approvals succeeded and failed, integration attempts by result, and time in pending state. A server can return 200 responses while the core business process is stuck. Define thresholds and the person who responds before alerts exist.
Operate automations as deployed products
Do not confuse background Tasks with product automations. A background Task is Agent building in an isolated copy of your project; it stops when the build work finishes. An automation is software you publish so an external trigger or schedule can keep running after you leave the editor. Create one from the signed-in Replit home screen by choosing Agents & Automations, then choose a currently supported Slack, Telegram, or Timed Automation trigger and describe the input, policy, action, and receipt.
Use the Agents & Automations pane beneath Preview to test the conversation or workflow and inspect its visual path and logs. Live Slack, Telegram, or scheduled triggers require deployment: event-driven agents fit Autoscale, while timed work fits Scheduled publishing. Begin with synthetic destinations, least-privilege connections, a duplicate-prevention key, a disable switch, and an owner. Custom webhook triggers are not a safe assumption until the current documentation says they are available.
- Build Task: changes the product in an isolated development copy.
- Slack or Telegram automation: reacts to an external message after deployment.
- Timed Automation: runs on a schedule after deployment.
- Testing pane proof: demonstrates development behavior, not a live trigger.
- Trigger proof: requires the deployed automation, timestamp, input, output, and logs.
Operate cost, security, and incidents
Set account and project spending controls available to you, then monitor Agent usage, database usage, publishing compute, requests, storage, and outbound transfer. Use the current pricing calculator and Usage dashboard rather than embedding a remembered dollar amount in a plan. Establish a normal weekly range and alerts before a traffic spike or runaway loop teaches the lesson expensively.
Run security checks before each material release, review dependencies, rotate credentials, and re-test permissions. For incidents, stabilize first: pause a dangerous integration, roll back the app when appropriate, or restrict access. Preserve timestamps and safe evidence, communicate impact plainly, recover, then write the causal chain and prevention work. Operation is the continuing practice of keeping promises after launch.
Working reference
Commands and patterns
Create a release evidence bundle
git status --short git log -1 --oneline git diff --check npm run test --if-present npm run build --if-present
Record the exact source state and declared checks before publishing. Adapt commands to the project's actual stack.
Production smoke probes
curl -fsS https://YOUR-DOMAIN.example/health curl -I https://YOUR-DOMAIN.example/
Verify a deliberately safe health endpoint and top-level response after publishing. These probes do not replace authenticated workflow tests.
Confirm production configuration names
node -e "console.log(['DATABASE_URL','AUTH_SECRET','INTEGRATION_API_KEY'].map(k => [k, Boolean(process.env[k])]))"
Use inside the intended environment only and record presence, never values. Actual names depend on the app.
When the happy path breaks
Failure modes
Symptom
Publishing succeeds, but authentication, data, or an integration fails at the public URL.
Likely cause
The release was tested only in development and production domains, secrets, callbacks, or databases differ.
Recovery
Use an environment matrix, verify production configuration and migrations, then run the full production smoke journey.
Symptom
The app is technically online but becomes slow, expensive, or unavailable under real use.
Likely cause
Publishing type and resource expectations were chosen without a workload or cost model.
Recovery
Measure requests, latency, CPU, memory, background needs, and idle behavior; change the publishing model or optimize the bottleneck.
Symptom
Monitoring is green while users cannot finish the main workflow.
Likely cause
The team observes host uptime but not application or business outcomes.
Recovery
Add critical-journey metrics, pending-age thresholds, failure rates, and a synthetic or manual smoke journey.
Symptom
A production rollback restores pages but corrupts or cannot read current data.
Likely cause
The release introduced a backward-incompatible migration with no coordinated recovery strategy.
Recovery
Use compatible migrations, back up and verify production recovery, and make code and data rollback decisions together.
Symptom
A builder closes Replit expecting a background Task to keep serving users or firing on schedule.
Likely cause
Agent's development Task system was confused with a deployed product automation.
Recovery
Choose Agents & Automations for the runtime, test it in the pane, publish it on Autoscale or Scheduled as appropriate, and verify a real trigger receipt.
Hands-on lab
Run a controlled production launch
Promote the authenticated workflow from development evidence to a monitored published app without skipping the go/no-go gate.
- 01Name the release candidate, freeze scope, review changes, run tests and build, and resolve or record every security finding.
- 02Estimate workload and choose a publishing type using current Replit documentation and cost controls.
- 03Complete the production environment matrix, configure secrets without disclosure, and apply verified migrations.
- 04Publish, connect or verify the intended domain, and record the release identifier and URLs.
- 05Run health, unauthenticated denial, authenticated happy path, cross-user denial, integration failure, and narrow-screen smoke checks.
- 06Enable appropriate monitoring, define workflow metrics and thresholds, set budget limits or alerts, and assign response ownership.
- 07Run an automation operator drill in a separate practice project: from the home screen choose Agents & Automations → Timed Automation and ask for a daily synthetic operations summary that reads a fixed JSON fixture and writes a structured result only to logs. Test it in the pane. If budget and authorization permit, publish with Scheduled deployment and verify one timestamped run; otherwise leave it undeployed and record that live-trigger proof is absent.
- 08Perform a safe rollback tabletop: name the exact code, configuration, database, domain, and communication steps without damaging live data.
Deliverable: A release packet containing the go/no-go decision, production map, live receipts, monitoring and budget proof, and an incident/rollback runbook.
Reusable artifact
Production release packet
Complete this for every material release; attach evidence rather than relying on memory.
RELEASE: [name, checkpoint, commit, date, owner] SCOPE / NOT INCLUDED: [changes and explicit exclusions] GO / NO-GO: [decision, approver, blockers, accepted risks] PUBLISHING TYPE / WORKLOAD: [choice and evidence] ENVIRONMENT: [database, secret names, callbacks, domains, build/start commands] MIGRATIONS: [applied version, result, compatibility] SECURITY: [scan result, permission tests, exceptions] SMOKE RECEIPTS: [health, happy, denial, failure, mobile] MONITORING: [uptime, errors, latency, resources, workflow signals] AUTOMATION: [trigger, synthetic test, deployment type, disable path, live-trigger receipt or explicitly not deployed] COST: [budget/limit, alerts, normal range, owner] ROLLBACK: [app target, data decision, verification, communication] PRODUCTION URL / RELEASE PROOF: [links and timestamp]
Before you move on
Receipt checklist
- The published URL and custom domain, if used, serve the named release over HTTPS.
- Production happy-path, unauthorized, cross-user, dependency-failure, reload, and narrow-screen checks pass with synthetic accounts.
- Security review, migration result, production configuration presence, and rollback target are recorded without secret values.
- Monitoring covers uptime, errors, latency/resources, and at least one critical workflow outcome with an owner.
- The automation drill has a testing-pane receipt and either a verified Scheduled run or an explicit not-deployed record; no development Task is represented as a live automation.
- A current spending limit, budget, or alert strategy is visible in the appropriate Replit account controls.
Primary sources
