Site Portability Guide

Site portability is the ability to package, document, deploy, restore, and operate a website or application outside the interface that originally built it. A site is not truly operational until it can be moved, reproduced, and restored on infrastructure the owner controls.

This is a positioning of ownership and reproducibility, not a rejection of builder platforms. AI builders are excellent for creating fast; portability is about protecting the resulting project as it becomes important.

A GitHub export is the single most important artifact for portability. It gives you:

• A version-controlled source of truth outside the builder.
• The ability to review dependencies, build steps, and configuration.
• A basis for reproducible builds, CI, and audits.
• An anchor for backups and disaster recovery.

Without an export, migration is limited to what can be captured through the builder's UI — which is rarely enough for a real production handoff.

Static or frontend-heavy projects (React/Vite, static HTML, docs sites) typically need:

• A verified build command (e.g. npm run build).
• A known output directory (e.g. dist/).
• An SPA-safe rewrite rule for deep links.
• HTTPS, caching, and compression at the edge or reverse proxy.

These can usually be hosted on managed static hosts, VMs, or bare metal without a runtime server process.

Backend migrations are meaningfully harder than frontend migrations. They involve:

• Auth providers, sessions, and user records.
• Databases, schemas, and Row-Level Security policies.
• Storage buckets and file access controls.
• Background jobs, scheduled tasks, and webhooks.
• Third-party integrations, API keys, and rate limits.

In many cases the pragmatic path is keep the external backend (for example, Supabase) and migrate only the frontend. A migration review clarifies which components can stay put and which need refactoring.

Environment variables tell an application how to behave in a given environment: API URLs, feature flags, keys. Secrets are the sensitive subset — API keys, tokens, signing keys — that must never end up in source control or client bundles.

• Static builds bake public env values at build time — re-build when values change.
• Server runtimes read env at request time — restart or redeploy to pick up changes.
• Never paste secret values into a migration request — variable names only.

Running on a VM, bare metal, or private cloud gives full control — and full responsibility. Owners take on:

• Operating system and security patching.
• TLS certificate renewal and rotation.
• Backups, snapshots, and restore drills.
• Log collection, monitoring, and alerting.
• Capacity planning and cost management.

This is a good trade for teams that need control, sovereignty, or specific compliance posture. It is a poor trade for teams without the operational capacity to keep it running.

• Confirm you own or have permission to migrate the project.
• Ensure the project is exported (or exportable) to GitHub.
• List the frontend framework and any known backend providers.
• Decide the target deployment (VM, bare metal, VPS, private cloud, managed hosting).
• List environment variable names — never values.
• Note the biggest migration concern (downtime, data loss, auth users, DNS).

• Site Portability Studio is a planned / early-access channel — not publicly live.
• Automated migration is not complete; every project needs assessment.
• We do not ask for passwords, do not store secrets, and do not fake deployments.
• We do not bypass licenses, terms, or platform protections.