Deploy a vibe-coded app

1. Know what you've got

Open the project, or ask your AI tool: "List the files in this project and say what each one does. Don't change anything." You're looking for three answers:

• What kind of app it is. A server you start (Node, Python, Go and so on) runs as a web service. A site that's only files once it's built, such as a React app made with Vite, can run as a static site instead.
• How it starts. A Node app has a start script in package.json. A Python app has a command like gunicorn app:app. A Dockerfile in the root means the build is already written down.
• What it calls. A hosted database, a sign-in service, a payments or AI API. The deployed app needs the same addresses and keys, as variables.

ComputeSphere doesn't host databases for you. If your app has one, keep it hosted where it is, or with any database provider, and pass its connection string in as a secret.

2. Fix the three classic problems

These are why vibe-coded apps work in the preview and fail, or leak, once deployed.

Keys in the code

AI tools often write an API key straight into a source file to make the first run work. Search the project for anything key-shaped (sk_, key, secret, token, password), and move each one into an environment variable:

// Before
const stripe = new Stripe("sk_live_51H...");
// After
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

If a real key was ever committed or shared, even in a private repository, replace it at the provider. Deleting the line leaves it in Git history.

Open data access

The demo works without checking who's asking, so the check often isn't there. For every route that reads or changes someone's data, try it signed in as a different user. You should get 403 or 404, never their data. If your database has its own access rules, such as row-level security, make sure they're switched on, not left open for the demo.

Listening on localhost, or on the wrong port

An app that listens on 127.0.0.1 or localhost only answers requests from the same machine. Online, requests come from outside it. Listen on 0.0.0.0, on a port read from the PORT variable with a default:

const port = Number(process.env.PORT) || 8080;
app.listen(port, "0.0.0.0");

Remember the port. You'll give ComputeSphere the same number.

And add a health check

Add a route such as /healthz that returns 200 once the app can serve. ComputeSphere uses it to decide when a new version is ready for traffic.

3. Push it to GitHub

If your tool connects to GitHub, use that: later changes reach your repository the same way. Otherwise create an empty repository on GitHub and push the folder:

git init
git add .
git commit -m "First commit"
git branch -M main
git remote add origin https://github.com/<you>/<your-app>.git
git push -u origin main

Before git add, check .gitignore lists node_modules/ and .env, so neither ends up in the repository.

4. Create the service

1. Create a project

   In the console, open Projects and choose New project. Give it a name and choose Create.

   You should seeYour project's page, with No services yet.

2. Start a web service

   Choose New service, then Web Service. Give it a short name, such as web.

   You should seeThe New service form, starting with Service information.

3. Pick an environment

   Under Environment, choose Create environment. Name it, for example production, pick a Region, and choose Create.

   You should seeYour environment selected under Environment.

4. Point it at your repository

   Under Configuration, choose Git repository. For a public repository choose Public and paste its URL. For a private one choose Private (Connections) and connect GitHub first, giving the ComputeSphere app access to only this repository (lesson 5.3.1). Set Branch to main.

   After you paste the URL, wait a moment, then check the fields below: the console reads the repository and can change them.

   You should seeYour repository URL and branch filled in under Configuration.

5. Choose how it's built

   Under Runtime, Build method has two choices:

   • Dockerfile if the repository has one. Dockerfile path is Dockerfile unless yours lives elsewhere.
   • Managed if it doesn't. Pick the Runtime environment and Version, then a Build command (for example npm ci && npm run build) and a Start command (for example npm start).

   You should seeBuild method set to Dockerfile or Managed, with its fields filled in.

6. Add variables and secrets

   Under Variables, add what your app reads from its environment. Settings anyone may see, such as APP_NAME, go under Environment variables. Anything that grants access, such as API keys and DATABASE_URL, goes under Secret variables: once saved, nobody can read it back. Import .env adds several at once from a file on your machine.

   You should seeEach setting your app reads, under Environment variables or Secret variables.

7. Set the port

   Under Networking, set Port to the port from step 2. Keep 1 spherelet for now.

   You should seePort under Networking matches the port your app listens on.

8. Deploy

   Choose Deploy. Open the service, then its Builds tab to follow the build log. When it shows Live, open the URL under the service name.

   You should seeDeploying service, then the service page shows Running and a URL ending in computesphere.app.

9. Add the health check

   Open the service's Settings. If the Health check card says Health checks not configured, choose Add health check. Fill in Endpoint path (/healthz), Port, Initial delay (5 seconds suits most apps) and Check interval (10), then Save and Redeploy now.

   The new service form has a health check section too. When we ran this guide, the check set there didn't appear in Settings afterwards, so confirm it here.

   You should seeThe Health check card shows Enabled, with your path and port.

5. Change something, and roll back

• New code: pushing to your branch doesn't deploy a service built from a public repository URL. Choose Redeploy, keep Build & deploy selected, and confirm. ComputeSphere builds the latest commit on the branch.
• A variable: in Settings, the Environment variables card, choose Edit, change it, then Save & redeploy.
• A bad release: choose ⋯ next to the service's actions, then Roll back. Pick an earlier version that shows Running and choose Roll back to v2 (the button names your pick). It restores that version's image, variables and health check, and keeps your spherelet count and domains.

Roll back first, then find out what went wrong while users are served.

What can go wrong