Tempo workflow

Take Tempo output live on EU infrastructure

Tempo turns a visual canvas into real React and Next.js code, then hands you the project. The one thing it does not decide is where the finished site runs. Point that build at VibeDeploy and it runs under EU jurisdiction on a flat plan, with your own domain and SSL included.

Deploy your Tempo site See pricing

Why VibeDeploy for Tempo

By the time Tempo's canvas matches your design, the code is standard React that any host can serve. The open questions are jurisdiction and cost shape. Sending the export to a US PaaS answers both one way; sending it to VibeDeploy answers them with EU data centres, a flat per-plan price, and GitHub-triggered redeploys that keep the workflow automated.

public

European serving for an exported build

The React project Tempo produces moves onto EU data-centre infrastructure with a DPA on every paid plan. Nothing about how you designed it in the visual editor changes.

shield_lock

A bill that ignores seat count

Hosting is a flat per-plan figure with domains and SSL folded in, rather than a per-seat editor charge that climbs as the team grows or a usage meter that climbs with traffic.

settings_suggest

Redeploys on every commit

Link the GitHub repository Tempo already syncs to and each push rebuilds and redeploys. Framework detection covers Vite, Astro, SvelteKit and static Next.js exports.

The Tempo to production workflow

1
Compose the app on Tempo's canvas
Keep designing the way Tempo intends: manipulate layout and styling directly while it emits real React and Next.js underneath. Deployable here is static and SPA output, meaning a Vite or React SPA, a static Next.js export, Astro, SvelteKit or plain HTML. Generate the production build once the preview satisfies you.
```
npm run build
```
2
Take the project off the platform
Tempo gives you two clean exits: its native GitHub sync pushes the repository straight across, or you open the project locally in VS Code and grab the compiled output folder, typically named dist or build.
3
Hand the build to VibeDeploy
Open a 14-day trial at vibedeploy.eu; no card is requested. From there, either link the GitHub repository so each push triggers a rebuild and redeploy, or drop the output folder onto the dashboard for a one-time publish. Both routes end at a live name.vibedeploy.eu URL.
4
Attach the domain you actually want
Add your own domain in the site settings and create a CNAME pointing at VibeDeploy. The certificate issues on its own, typically inside a minute, and the platform subdomain keeps serving until it does.
5
Optional: let an MCP client do the deploying
Open the exported Tempo project in Claude, Cursor, Windsurf or another MCP-capable client and it can deploy through the VibeDeploy MCP server at https://mcp.vibedeploy.be/mcp. Note the boundary: this runs from your editor, because Tempo's own IDE does not connect to external MCP servers.

Tempo hosting at a glance

How Tempo's default hosting and a generic alternative compare to VibeDeploy.

Feature	Tempo default / generic alt	VibeDeploy
Hosting location	You choose (often US PaaS)	EU (Belgium)
Pricing model	Per-seat editor	Flat per plan
Custom domain	On your chosen host	Yes, on every plan
Automatic SSL	On your chosen host	Yes
Best fit	Visual React development	Static / SPA front-ends

Common questions about deploying Tempo

Does VibeDeploy run the Supabase or Stripe backend Tempo wired up?expand_more

The Supabase auth and data layer and Stripe payments that Tempo connects are external services your front-end reaches from the browser, so they carry on working from a static deploy. What a static-edge host will not run is an always-on server of your own; leave any such backend on a server host and bring the front-end layer here.

Why host a Tempo build on VibeDeploy instead of a US PaaS?expand_more

The decision usually turns on two properties. Jurisdiction: serving from Belgium keeps European visitor data under EU law, whereas the common default targets sit in the US. Billing shape: a VibeDeploy plan is one flat figure with domains and SSL already inside it, not a per-seat or per-usage charge.

What about a Next.js site from Tempo?expand_more

Configured for static export or SPA mode, Next.js deploys without adjustment. The part that does not carry over is the server side: SSR and API routes need a running Next.js process, which a static-edge host does not provide. Server-rendered apps belong on a server host; exported ones deploy here as-is.

Do I have to use GitHub, or can I upload once?expand_more

Both paths share the same hosting. Many people drag the build output onto the dashboard first to see the site live, then wire up the GitHub repository Tempo syncs to so later pushes redeploy on their own. Moving between the two costs nothing.