Read-only access
A GitHub App with a one-click install grants read-only access to your source code repository. The assessment runs static source and dependency analysis only, no writes.
How it works
Assess, Migrate, & Launch
Three self-guided stages take your MVP to preferred cloud provider.
The migration at a glance
Eleven steps across three stages
Trained migration agents orchestrate migrations across 11 sequential steps.
Step 1 of 11Assess
Connect your app
Link your source repository and application details so the assessment can begin with read-only access.
Selected step 1 of 11: Connect your app. Link your source repository and application details so the assessment can begin with read-only access.
Stage 1
Assess
Review the application, dependencies, and scope with read-only access, then receive a report and a recommended migration plan.
Link your source repository and application details so the assessment can begin with read-only access.
Add the prompt history exported from your vibe-coding platform to give the assessment richer context.
A read-only static assessment reviews source, dependencies, and configuration for risks before anything changes.
The assessment compiles findings into a report with a recommended scope and target architecture.
Selected phase: Connect your app.
Stage 2
Migrate
Provision dedicated infrastructure on your chosen cloud provider and let the agents carry out the approved migration plan.
Approve the one-time migration fee for the scope recommended in your assessment report.
Dedicated infrastructure is provisioned in a cloud account you own on your chosen provider.
The approved scope becomes an ordered plan of build and verification steps for the agents to follow.
Agents work through the roadmap with a build, verify, and deploy loop, escalating to a person whenever a step needs review.
Selected phase: Pay for migration.
Stage 3
Launch
Verify the migrated environment, cut over your domain, and hand off to self-operation or optional Managed Hosting.
Point your domain at the migrated environment so production traffic flows to your new infrastructure.
Choose optional Managed Hosting for ongoing operations, or take a self-operated handoff.
Reconnect the native builder or an IDE like Cursor, Kiro, or Visual Studio to keep shipping features.
Selected phase: Update DNS records.
Optional after launch
Keep shipping with Managed Hosting
Managed Hosting is enabled by default for every migrated app, so you keep building while we operate the environment. You can always take full ownership instead.
| What you get | Managed HostingRecommended · Most popular | Self-managed |
|---|---|---|
| Cloud account and repository | Stay in the Vibe2Cloud organization so we can monitor and maintain them. | Transferred to you at handoff; you host and manage them yourself. |
| Support cases | Open a support case at any time. | Not included. |
| Infrastructure maintenance | Patching, runtime upgrades, and incident response are handled for you. | You handle patching, runtime upgrades, and incident response. |
| Native builder interface | Keep shipping in a familiar builder, with a stronger harness, steering, and deployment guidance. | Bring your own tooling and IDE. |
| Environment responsibility | Vibe2Cloud operates the environment while you keep full ownership rights. | You take full responsibility for operating the cloud environment. |
| Price | $149 per month per app. Enabled by default for every migrated app. | No operating fee. You pay your cloud provider directly for usage. |
Security and ownership
How we protect your application
Migrations are built around least-privilege and workload isolation.
Original repo never modified
Migration work happens in a new repository cloned from your source. The app you are running today stays exactly as it is until you decide to cut over.
Dedicated cloud account
Each customer workload is provisioned into its own dedicated cloud account for strong isolation, with no shared infrastructure between customers.
Human escalation
Migration runs on a build, verify, and deploy agentic loop orchestrated by trained migration agents. When a step cannot be verified after retry thresholds are met, agents escalate to humans for review.
Encryption and secrets
Data stores in the target environment are encrypted by default, and every secret is kept in a secure credential store like AWS Secrets Manager rather than in your code.
Fully auditable
Every migration follows a sequential, spec-driven process guided by requirements, design, and task documents you can download before and after the migration.
The migration engine
Automated build, deploy, and verify agentic loop for every migration
Trained migration agents move your app one spec at a time while a deterministic harness deploys and verifies each step. A spec is a self-contained unit of work with its own requirements, design, and tasks, which keeps every change focused.