How to Move a Website or Web App Off Manus: A Safe Migration Guide for Affected Users

If you built a website or web application on Manus, the most valuable asset is not the hosting layer. It is the combination of your source code, data, assets, domain, integrations, and operating knowledge. A clean migration makes each of those pieces independently recoverable and deployable.

First, an important distinction: Manus’s August 11, 2026 notice says that the company is returning to independent operations and that some users’ accounts and data are affected by the transition. It is not a notice that the service is shutting down for everyone. Affected users have a backup window that ends at 7:59 a.m. SGT on August 23, 2026, followed by a restoration portal opening at 8:00 a.m. SGT on August 25, 2026. Confirm whether your account is affected in the official notice before acting. [1]

This guide is for teams that are affected, want a contingency plan, or simply want to run their project on infrastructure they control. It uses Render as a concrete example, but the sequence also applies to comparable hosts such as Railway, Fly.io, Google Cloud Run, AWS, or a managed Kubernetes platform.

Do not treat a deployment as a backup. Before changing DNS or credentials, make separate copies of your source code, database export, asset inventory, configuration inventory, and rollback records.

The migration at a glance

1. Freeze the inventory before you move anything

Start by recording the current production shape of the application. Create a migration worksheet with the repository URL and branch, the build and start commands, the database provider, storage locations, custom domains, background jobs, OAuth providers, webhooks, analytics tags, and every environment-variable name. Do not put secret values in this worksheet.

If your project is connected to GitHub, verify that the latest production code is committed and push a final migration tag such as pre-migration-2026-08-11. If it is not connected, create a private repository and make an export before working on the host. Keep the lockfile—pnpm-lock.yaml, package-lock.json, or yarn.lock—because it makes the new build reproducible.

For affected accounts, use Manus’s official backup tool within the stated window. The official notice describes both the backup deadline and the temporary access interruption before restoration, so do not leave this until the DNS cutover day. [1]

2. Choose the simplest independent architecture

Choose hosting based on what your application actually runs, not on the tool that created it.

Render’s Node/Express guide documents a repository-connected Web Service with explicit build and start commands. It also notes that new pushes to the linked branch build and deploy automatically, while a failed build leaves the current successful version running. [2] That behavior is useful for a cautious migration because you can validate a Render URL before moving traffic.

3. Export the code and remove platform assumptions

Clone the repository on a clean machine and run the application locally using a safe development configuration. Before deploying anywhere new, identify assumptions that are tied to the old platform.

Common examples include a proprietary OAuth provider, storage helper, database URL, deployment-specific analytics identifier, scheduled-job SDK, preview-domain allowlist, or a server that has a port hard-coded to 3000. Replace the last case with process.env.PORT and make the server bind to the host-provided port.

Add an .env.example file containing only names and non-sensitive placeholders, for example:

NODE_ENV=production
DATABASE_URL=replace-with-production-connection-string
SESSION_SECRET=generate-a-new-long-random-value
OAUTH_CLIENT_ID=replace-with-provider-client-id
OAUTH_CLIENT_SECRET=replace-with-provider-client-secret
PUBLIC_APP_URL=https://www.example.com

Do not export a .env file to Git, a ticket, a chat transcript, or an article. If an old platform injected a value such as a platform API key, identify the underlying capability it enabled and replace it with an account and credential you control. In practice, that may mean creating your own database, storage bucket, OAuth application, email sender, or analytics property.

4. Copy assets deliberately—not just the code

Repositories rarely contain every production file. List every place assets can live: public folders, upload buckets, CDN paths, attachment tables, generated reports, and email templates. Download or export those files into a controlled migration archive, then upload them to a destination you own, such as an object-storage bucket with a CDN.

Create a manifest with the original URL, destination URL, file size, checksum, content type, and whether the file is public or private. This lets you identify 404s after cutover instead of discovering them from customer reports.

For public assets, preserve stable paths where possible. If paths must change, update database records and application configuration before DNS cutover. For private files, do not turn the entire bucket public to “make the migration work”; reproduce authorization rules and use short-lived signed URLs where appropriate.

5. Recreate environment variables and secret files safely

Treat secrets as a fresh setup, not as a file copy. Gather values from the password manager or the original provider dashboards, rotate anything that may have been exposed, and enter them directly in the new hosting environment.

Render recommends environment variables for runtime configuration and sensitive credentials such as API keys or database connection strings, rather than committing them to the application source. It also supports plaintext secret files at runtime and reusable environment groups for multiple services. [3]

Keep a redacted configuration checklist that records whether each key has been configured and tested. It should never record the value itself.

6. Deploy to Render before changing DNS

For a Node/Express application, create a Render Web Service, connect the private repository, and set the exact commands that work locally. A typical build command might be pnpm install --frozen-lockfile && pnpm build, while the start command might be pnpm start; use the commands your own project defines. Render’s guide supports this repository-connected workflow. [2]

Add a lightweight GET /health endpoint that checks only application readiness—avoid querying every external dependency if that would make routine checks flaky. Configure it as the host health check, deploy to the temporary onrender.com URL, and test these flows before pointing a custom domain:

• the home page and a representative deep link;
• the login/logout path;
• database reads and one carefully controlled write;
• file upload/download or public asset delivery;
• transactional email, webhooks, and background work;
• robots.txt, sitemap.xml, canonical tags, and redirects.

If the application has schema migrations, run them through a controlled one-off job or release step. Do not let multiple new service instances attempt a destructive migration on startup.

7. Migrate the database with a planned write cutover

Database migration is the point at which “it looks fine in preview” can become production data loss. Export from the existing provider, provision the target database, import the schema and data, then compare row counts for critical tables. Sample real records—especially users, orders, uploaded-file references, and settings—not only aggregate counts.

When you are ready to cut traffic over, decide how you will prevent diverging writes. The simplest approach for a small app is a short maintenance window: stop writes on the old deployment, make a final data export/import, validate, then switch DNS. More complex systems may need replication or a dual-write plan, but do not improvise one during an outage.

Make a rollback decision before starting: if validation fails, do you restore the old DNS records and resume writes on the old system, or keep the new system read-only while you fix it? Write that answer down.

8. Switch DNS only after the new domain is verified

Add the custom domain in Render first. Render’s documented sequence is: add the domain in the Render Dashboard, configure the DNS record with your domain provider, and verify the domain in Render. Render also states that it provisions and renews TLS certificates for custom domains and redirects HTTP to HTTPS. [4]

Before editing DNS, export or screenshot the existing zone. Preserve mail-related records such as MX, SPF, DKIM, and DMARC; a website migration normally changes only the web host records. For the apex and www hostname, use the exact record type and target that Render displays for your service. Do not guess an IP address or copy a record from another provider.

Lower TTLs ahead of time only if the existing TTL will have time to expire before cutover. When you switch records, keep the old deployment available until you have verified the new one globally and completed the functional test plan. DNS resolution can remain cached according to the prior TTL, so communicate a transition window rather than promising an instant global change.

9. Validate propagation and the application, not just the homepage

Use two levels of validation: infrastructure checks and user-flow checks. A green TLS certificate does not prove that a login callback, a background job, or an uploaded asset still works.

Keep a timestamped cutover log with the DNS change, the deploy version, the database export time, and the person who completed each check. It makes rollback and incident review much less ambiguous.

10. Keep a short rollback window

Do not immediately delete the prior deployment, DNS records, or backups. Keep enough access to reverse the change while caches expire and real user traffic exercises the new system. If a critical defect appears, restore the saved web records, pause writes if necessary to avoid data divergence, and use your cutover log to identify what changed.

Once the new service has run cleanly through normal traffic, archive the old deployment configuration and revoke old credentials that are no longer needed. A completed migration is not just “the site loads”; it is a tested, documented, independently operated application.

Copy-and-paste prompt kit for an orderly handoff

If you still have access to the original project workspace, ask for structured deliverables before you change hosting. A clear prompt can reduce the chance of losing a configuration file, a generated asset, or an operational detail that is not obvious from the application code.

Prompt 1: Create a complete project export

Use this prompt to request an archive suitable for a developer or a new hosting provider. It explicitly asks for a manifest and keeps secrets out of the archive.

Please export all files from this project session into a single ZIP folder with no truncations or omitted source files.

Before creating the ZIP, include a PROJECT_EXPORT_MANIFEST.md at the archive root that lists every exported file, its purpose, and any known generated or environment-dependent files. Include application source, configuration, lockfiles, database schema and migration files, public assets, documentation, test files, deployment configuration, and a redacted .env.example containing variable names only.

Do not include live secret values, private keys, production .env files, access tokens, or database passwords. Instead, add a SECRETS_REQUIRED.md file that lists each required secret by name, what it is used for, where it should be recreated, and whether it is needed at build time, runtime, or both.

Preserve the directory structure and do not replace long files with summaries. At the end, provide the ZIP filename, total file count, and SHA-256 checksum so I can verify the download is complete.

Prompt 2: Ask for an agentic deployment handoff

Use this prompt after you have chosen a destination such as Render, Railway, Fly.io, Cloud Run, or another host. It asks for a handoff document an agent or developer can execute without guessing.

Create a handoff.md file for an agentic deployment of this project to [TARGET_HOST]. Write it for an engineer or coding agent that has the exported repository but no access to this current workspace.

The handoff.md must include:
1. A concise architecture overview, including frontend, backend, database, storage, background jobs, third-party integrations, and custom domains.
2. Exact local setup, build, test, database migration, and production start commands, including the required Node/package-manager versions.
3. A complete environment-variable and secret-file inventory by NAME only. For each item, state its purpose, source system, build-time or runtime scope, and whether it is required in production.
4. Deployment instructions for [TARGET_HOST], including service type, build command, start command, health-check path, persistent storage needs, scheduled jobs, and expected port behavior.
5. Database migration and cutover steps, including how to take a final backup, validate schema/data, avoid diverging writes, and roll back safely.
6. Asset migration instructions, including every bucket/CDN/public-files location and how to validate file URLs after deployment.
7. Domain, DNS, TLS, OAuth redirect URI, webhook, analytics, and email-sender changes required for cutover.
8. A production validation checklist covering routes, authentication, payments or other critical workflows, assets, APIs, logs, error tracking, sitemap/robots/canonical tags, and rollback criteria.
9. A section called "Known platform dependencies" that identifies every feature currently tied to this platform and explains the replacement or manual action required on [TARGET_HOST].

Do not include any live secrets, access tokens, private keys, or database passwords in handoff.md. Do not omit files or summarize code paths that are necessary for deployment.

Prompt 3: Ask for a migration-readiness review

Run this final review before you switch DNS. It is designed to reveal hidden dependencies and places where a new host will behave differently.

Review this project for migration readiness to [TARGET_HOST]. Return a prioritized checklist of blockers, risks, and required changes.

Specifically inspect for platform-specific SDKs, generated environment variables, proprietary authentication, storage helpers, database connections, background schedules, port binding, file-system assumptions, callback URLs, webhooks, analytics, email, payment integrations, CORS rules, CSP rules, SSR/SEO behavior, and DNS/TLS dependencies.

For each finding, provide: severity, affected files, why it will fail or behave differently on [TARGET_HOST], the recommended replacement, the exact validation step, and a rollback consideration. Do not make changes yet; produce the review first.

The practical takeaway

The safest way to move off any managed app platform is to separate the work into reversible layers: source code, assets, data, secrets, deployment, DNS, and validation. Build and test the new system first; move the domain last. For affected Manus users, begin the data backup immediately and follow the official timeline—not a rumor about a universal shutdown. [1]

References

[1] Manus, “A Note to Our Users”

[2] Render, “Deploy a Node Express App on Render”

[3] Render, “Environment Variables and Secrets”

[4] Render, “Custom Domains on Render”