Port an existing repo

import { Aside, Steps } from ‘@astrojs/starlight/components’;

Melbora’s provisioning orchestrator only creates fresh repos from the website-template — there’s no “import existing repo” command. So porting an existing project means provisioning a new Melbora website and migrating your code into it.

What you get from porting

Vercel project owned by Melbora’s team
CMS document the client can edit through their portal login
Blueprint canvas with all services visualized
SEO scanner + GEO probes against the live site
Domain management through the CLI
Optional Shopify / channels / bookings / Resend wiring
All future Melbora features (changelog notifications, multi-channel publishing, etc.)

Prerequisites

Melbora CLI installed and logged in (see Quickstart)
Your existing repo, locally
The website-template is Next.js App Router — if you’re already on Next.js App Router, this is a copy-paste job; if not, you’re rewriting routes

Steps

Provision an empty Melbora website.
Terminal window
```
vantage websites create --name "Your Site" --slug your-slug
```
Pick a slug that reads well in URLs. The orchestrator creates github.com/Vantage-Connections-Org/client-your-slug from the template, plus a Vercel project, plus a first deploy.
Wait for status: "active".
Terminal window
```
vantage websites get <websiteId>
```
Poll every 30 seconds until status: "active". Should take 60-90 seconds.
Clone the new repo locally.
Terminal window
```
git clone https://github.com/Vantage-Connections-Org/client-your-slug
cd client-your-slug
pnpm install
pnpm dev
```
You should see the default template at http://localhost:3000. Familiarize yourself with the layout before merging your code in.

Plan your migration page-by-page.

Identify what each piece of your existing repo maps to:

Your code	Where it goes in the template
A page / route	`app/<segment>/page.tsx`
A reusable component	`components/<Name>.tsx`
Static assets (images, fonts)	`public/<path>`
Static content (copy, headings)	The CMS document — see step 6
Backend logic	Either Melbora API or a Vercel route handler
Environment variables	Vercel project env, or `vantage websites features` if it’s a built-in
Styles (CSS modules / Tailwind)	Template uses Tailwind — port classes directly

Migrate pages.

Server components are the default. Mark "use client" only where you need client-side interactivity (forms, hooks, browser APIs).
app/about/page.tsx
```
export const metadata = { title: "About — Your Site" };

export default function AboutPage() {
  return <main>{/* your content */}</main>;
}
```

Move static content into the CMS document.

The CMS document is a JSON blob the client can edit through their portal. The template reads it at request time.

// app/page.tsx — reading content
import { getContent } from "@/lib/content";

export default async function HomePage() {
  const content = await getContent();
  return (
    <main>
      <h1>{content.hero.heading}</h1>
      <p>{content.hero.subhead}</p>
    </main>
  );
}

Push the initial document via the CLI:

vantage content edit <websiteId>

This opens $EDITOR with the current content (empty for a fresh site). Save with the schema your template expects.

Set environment variables.

For built-in features:
Terminal window
```
vantage websites features <websiteId> --openrouter --resend
```
For custom env vars (third-party API keys, etc.), use Vercel’s project settings directly.
Push your changes.
Terminal window
```
git add -A
git commit -m "Migrate site content from <old-repo>"
git push
```
Vercel auto-deploys on push. Watch the deploy in the portal Blueprint (Vercel node).
Attach your domain.
Terminal window
```
vantage domains add <websiteId> --domain yourdomain.com --kind site
```
Set the DNS records Melbora prints at your registrar. Status flips to active once DNS resolves.
Verify everything in the Blueprint.

Open https://vantageconnections.dev/admin/websites/<websiteId>. All nodes should be green. If anything’s red or warned, click into the node — the drawer has the failure detail.

Gotchas

Things that have bitten porters before — none are blockers, but finding them on launch day is worse than finding them now.

The CMS schema is yours to define, not fixed by the platform. The API stores arbitrary JSON at content/settings/site.json. The template’s lib/site-content.ts defines a TypeScript type for that JSON and exposes getContent(). You widen the type and the JSON shape together — the platform doesn’t constrain either.
The template’s app/page.tsx is starter content meant to be replaced. Nothing in the platform reads it. You can rm -rf everything outside of lib/site-content.ts, content/settings/site.json, and public/uploads/ without breaking the Melbora contract.
Media uploads commit binaries to git. /uploads/<timestamp>-<name>, 8 MB ceiling per file. Built for “swap the hero image” frequency, not “ten product photos per SKU.” For image-heavy sites, route uploads to Vercel Blob or S3 from your own code instead of the CMS media endpoint.
Provisioning is async — nothing else works until status: "active". vantage websites create returns in ~50ms with status: "provisioning". Repo, Vercel project, and first deploy land over the next 60–120s. Calling vantage content edit or vantage domains add before active errors with “Website has no GitHub repo yet.”
Two env-var surfaces, no overlap. Platform features (Shopify, Resend, etc.) → vantage websites features <id> --shopify --resend, which pushes the right *_API_KEY vars to Vercel for you. Arbitrary app vars (your Sentry DSN, Stripe publishable key, your own analytics ID) → set in the Vercel project settings directly. Knowing which surface owns which variable is the operator’s job.
Optimistic concurrency on CMS writes. Save returns 400 "Someone else saved while you were editing" when the SHA is stale. The portal editor handles this; a migration script that programmatically writes the doc should GET → mutate → PUT-with-sha → refetch and retry on 400.
The repo lives under Vantage-Connections-Org, not the client. If a client leaves the platform, exporting their site is a manual GitHub repo transfer plus un-wiring the Vercel project. There’s no one-click export. Set the expectation up front.
GSAP / ScrollSmoother under App Router. ScrollSmoother mounts the wrapper once globally — put it in app/layout.tsx inside a "use client" boundary, not per-page. Dynamic-import the GSAP plugins so they don’t trip SSR. Pages can still be server components; only the animation root is client.
SEO scans bill against the website’s AI quota. Tier determines the rate limit. Running scans in a tight loop during dev will hit it. Use the lowest tier during migration; bump it after launch.
Blueprint node colors lag webhooks by 10–30s. Vercel deploy success and Shopify webhook health flow into the canvas async. After git push, expect a short delay before the Vercel node turns green. Not a bug, just don’t refresh in a panic.

Alternative: bring-your-own repo (no Melbora management)

If your repo can’t or shouldn’t be reshaped — for example a Vite SPA, a backend-heavy app, or a Vercel-incompatible stack — you can still host under Melbora’s Vercel team but you give up the platform features.

Add the Melbora GitHub bot as a collaborator on your repo (or transfer to Vantage-Connections-Org).
In Vercel, switch to team team_EffhFbPYbT1sia4Ns8yrOJxS, click Import Project, select your repo.
Configure the build settings Vercel needs (framework preset, build command, output dir).
Add your domain in Vercel directly.

What you lose with this approach:

The site will not appear in vantage websites list
No Blueprint, no CMS, no SEO scanner, no CLI control
Melbora is essentially a hosting account for this repo

What you keep: just Vercel hosting under Melbora’s billing.