AI App Builder With Vercel: Deploy to Your Own Account

AI App Builder With Vercel: Deploy to Your Own Account

Vercel is one of the built-in integrations in Zugo. Publishing inside the builder already puts a project live at a yourproject.zugo.run address. The Vercel integration answers a different question: it deploys the project to hosting that belongs to you, under your account, with your settings.

Most projects never need it. The ones that do need it badly, and they usually discover that on the day somebody asks who controls the server.

What does deploying to your own account change?

Three things, and they are all about control rather than speed.

The hosting relationship becomes yours. The account, the billing, the region settings and the deployment history sit with Vercel under your login. Nobody has to grant you access to your own site because you never lacked it.

The project stops depending on one subscription. A build published inside the builder lives where the builder puts it. A build deployed to your own hosting keeps serving on infrastructure you pay for directly, which is a meaningfully different answer to the question of what happens if you stop using a tool.

And configuration opens up. Environment variables, redirects, headers, preview deployments for changes before they go public: the ordinary controls of a hosting platform become available because you are standing on that platform rather than beside it.

What it does not change is how the project was made. It is the same generated code, verified in a sandbox before it reached you, doing the same thing. Deploying it elsewhere moves the serving, not the substance.

Publishing to zugo.run or deploying to Vercel: which do you need?

The honest reading is that the last row is the trade. Owning the hosting means owning the outages, the configuration mistakes and the renewal reminders. That is a fair price for control and a bad price for a weekend project that just needs a link.

A reasonable default: publish inside the builder while you are still deciding whether the project deserves to exist, and move to your own hosting once it has users, a client, or a name printed on something. The one-click route is covered in how to publish what you built.

What do you need before you connect it?

A Vercel account, which is free to create, and the willingness to be the person responsible for it afterwards. That second requirement sounds soft and is the real one.

A decision about the domain. Serving from your own hosting means the domain settings live there too, so it is worth knowing in advance whether you are pointing an existing domain at the deployment or registering a new one. The DNS mechanics are the same either way, and the custom domain guide covers them.

An idea of who else needs access. If this project belongs to a client or a team, invite them properly at the hosting level rather than sharing a login. That is a five-minute habit that prevents the most common ugly situation in freelance work, which is a site nobody can update because one person left.

Nothing else. You do not need to understand the build pipeline, and you do not need to write configuration by hand for a standard project.

How does this fit with GitHub export?

They solve neighbouring problems and get confused constantly. GitHub gives you the source code. Vercel gives you the serving. Supabase gives you the data.

Together those three make a project independent of any single subscription, including the builder's. The code sits in your repository, the site runs on your hosting, and the database is a project under your account. Each of them is useful alone, and the combination is what people mean when they say a project is genuinely theirs.

The order that causes least rework: export to GitHub first, then deploy, because a deployment fed from a repository is the arrangement any developer expects to inherit. What actually lands in that repository is covered in the GitHub integration.

If you are only doing one of the three, do the export. Code you hold is the thing that cannot be recreated. Hosting can be moved in an afternoon; a project you never exported cannot be reconstructed from a screenshot.

What does it cost?

Deployment is configuration rather than generation, so it does not consume credits by itself. Credits pay for what the agent produces: an edit costs 3, a build costs 6, and a multi-page platform costs 12 for the first three pages plus 3 for each page beyond them. Hi-Fi mode doubles both, so a build is 12 and an edit is 6.

Free includes 5 credits, Pro is $25 per month for 200 credits, and Business is $99 per month for 800. Two hundred credits works out to roughly 16 platforms, 33 builds or 66 edits when spent on one kind of action.

Hosting costs are separate and belong to your Vercel plan, on whatever terms you agreed with them. That separation is the point rather than an inconvenience: the bill for serving your site arrives from the company serving it, and it does not stop when a subscription elsewhere does.

The practical consequence for planning is that moving to your own hosting does not make building cheaper or more expensive. It changes who receives which invoice, and it changes who gets the alert at two in the morning.

What do you take on when hosting moves to you?

Four responsibilities, none of them heavy on their own.

Keeping the two copies in step. A deployment reflects the project as it was when you deployed it. If you keep editing in the builder afterwards, the deployed version does not change until you deploy again, and a project that has drifted for a month is the version your visitors are actually seeing.

Secrets. Keys for payments, email or anything else belong in environment variables on the hosting side, not in the code and not in a repository. Anyone who has ever pasted a key into a file and pushed it knows why this line exists.

Uptime and monitoring. A managed publish means somebody else notices when things go wrong. Your own hosting means you notice, which in practice means setting up something that tells you rather than relying on a customer's email.

Domains and certificates. These mostly manage themselves now, right up until a renewal or a DNS change makes them your problem for an afternoon.

When should you not bother?

When the project is a test, a personal page, or something you will judge in a fortnight and probably delete. One-click publishing exists precisely for that, and adding a hosting account to it is ceremony rather than progress.

When you are not the technical person and nobody else is either. Owning infrastructure with no one to look after it is worse than borrowing infrastructure that is looked after. There is no prize for holding a responsibility you cannot exercise.

And when the honest answer is that the project has outgrown the approach entirely. A builder does not replace a development team on a complex product, and very specific business logic is reached through repeated edits rather than one description. When that is where you are, the useful move is a handover with the code and the hosting in place, not a different deployment target.

None of those cases are failures. They are just situations where the simpler path is also the correct one.

Where to start

Build the project, get it working, and publish it the easy way first. Judge it live for a week. If it survives that and starts to matter, export the code, connect Vercel, and deploy from the repository.

Do the move before it is urgent. Migrating hosting while a client waits is a different experience from doing it on a quiet Tuesday, and the steps are identical.

You can build, publish and export the whole chain at zugo.dev. Start with the one-click version. Independence is worth having, and it is worth having on a project that earned it.