Key idea
Whatever built your app, production starts with the code in a Git repository you own. That's what you review, test, roll back and deploy from. An app that lives only inside a builder's editor can't be any of those things.
Into a repository you own
App builder or agent
Your source of truth
ReviewTestRoll backDeploy, laterA local copy
Where you run it and change it
There are two ways into this path. If you've already built something with an app builder or an agent, bring it. If not, use the starter app: a small tasks app, written the way an agent might write it, flaws included. The lessons use the starter, and every fix applies to your own app too.
Most app builders can either connect to GitHub and push the project to a new repository, or download it as a zip. Look in the project's menu or settings for GitHub, Export or Download. Prefer the GitHub connection: later changes in the builder can reach your repository the same way.
With a zip, create an empty repository on GitHub, then push the folder to it:
cd my-app
git init
git add .
git commit -m "Import from app builder"
git branch -M main
git remote add origin https://github.com/<you>/my-app.git
git push -u origin main
Before git add, open .gitignore. It should list node_modules/ and any .env file, so neither ends up in the repository.
On GitHub, fork github.com/computesphere-samples/learn. A fork is your own copy of the repository, under your account. Then clone your fork and move into the starter's folder:
git clone https://github.com/<you>/learn.git
cd learn/labs/vibe-starter
The starter is Node 20 and Express: a web page, a JSON API for tasks, and tasks kept in memory.
Look at what you've got
Open the project in your editor, or ask your agent: "List the files in this project and say what each one does. Don't change anything."
Check three things before you go further:
- How it starts. A Node app has a
package.jsonwith astartscript. Other languages have their own equivalent. - No real secrets. Search the code for keys, passwords and tokens. Builders sometimes write them straight into source files. If you find a real one in a repository, even a private one, treat it as leaked and replace it at the provider. The starter has a fake one on purpose; module 6 moves it out.
- What it calls. A builder may have set up a hosted database or sign-in service for you. The code keeps using it after export, and it needs that service's keys to run.
The builder's own preview stops working after export?
Some builders inject settings at run time, such as the address and key of the database they created for you. Exported code expects those as environment variables it no longer receives. Look for names like DATABASE_URL or API_KEY in the code; the next lesson shows how to supply them on your machine.
Check yourself