Skip to main content

Start from a reference app

The reference apps aren't only examples to read — you can use one to stand up a working stack in your own repository, entirely inside CoderFlow with no local setup. You import a reference environment, confirm it runs, have an agent copy the app into your repo, then point the environment at your repo.

The steps below use .NET + Angular as the example, but the flow is identical for every combination — just swap the combo name. For how each individual stack is wired, see the examples and the Stack reference.

What you'll need​

  • Permission to create environments and run tasks. See Environments.
  • A Git repository of your own, with CoderFlow granted write access — so it can open a pull request into it.

1. Import and run the reference app​

Go to Environments → Import Environment → Git repository, click Load environments, pick a combo (for example dotnet-angular), and click Import. The reference repo URL is already filled in.

Open the imported environment, go to the Build tab → Build Now, then Save.

Now confirm it runs: from the home page, create a task (type anything, such as Hello), then open the task's Testing → Start Server & Launch and click the Launch URL. You should see "Hello from the .NET API!".

Why start here

Running the reference app first proves the whole stack works — runtime install, build, and the live preview — before your own repo is involved. If anything is off, you catch it now, against known-good code.

2. Add your repository​

On the environment's Repositories tab, click Add Repository → With Git Provider, choose your provider, then select your repository and branch. For a private repo this is the normal path — the provider supplies the credentials (Manual Entry with a raw URL is mainly for public repos). Pick a provider with write access so CoderFlow can push your approved changes back to your repo; if your host isn't listed, a Git Provider needs to be configured for it first. Leave the reference repo attached — you'll copy from it in the next step. Then Build → Build Now → Save so the newly added repo is cloned into the environment and available to the task in the next step.

3. Copy the app into your repo​

Create a task in this environment and ask the agent to bring the app across, for example:

Copy the dotnet-angular app (the api/ and web/ folders) into my repository.

By default that lands the app as api/ and web/ at your repo root. If your project uses a different layout, tell the agent where to put it — for example "…into src/MyApi and frontend." Whatever you choose, note the destination: you'll point the environment at it in step 4, and that's the only place it matters.

When the task finishes, review the diff and Approve. In the approve dialog you choose how the change lands in your repo — push to a branch, push to a new branch, or Create pull request (which you then merge). Once it's pushed, your repository contains the app.

note

The agent only copies files into your repo, and nothing is pushed until you review and approve it — so you stay in control of exactly what lands in your repository.

4. Point the environment at your repo​

Two settings need to point at your repo's code (the import left them aimed at the reference app):

  • Post-clone action — on the Repositories tab, on your repo's entry. Set it to install the app's dependencies: cd /workspace/your-repo/api && dotnet restore then cd /workspace/your-repo/web && npm install.
  • Start command — on the Application Server tab. Set it to run the app: cd /workspace/your-repo/api && dotnet watch run & then cd /workspace/your-repo/web && npm start.

Use whatever directories the app landed in at step 3 — the examples above assume api/ and web/ at your repo root; adjust them (e.g. src/MyApi + frontend) for a custom layout. These paths are the one thing the build depends on: if one doesn't point at a real directory, the build fails when it tries to cd into it.

Your repo's branch was already set when you added it in step 2 (usually main), so there's nothing to change there — just make sure step 3's change landed on that branch, e.g. by merging the pull request.

Then Build → Build Now → Save, create a task, and open Testing → Start Server & Launch again. You should see "Hello from the .NET API!" — now served from your own repository.

5. (Optional) Detach the reference repo​

Once your repo builds and runs on its own, the reference repo isn't doing anything — the app was copied into your repo, and its dependencies come from public package registries, so nothing depends on it anymore. On the Repositories tab, remove the reference repo, then Build → Build Now → Save. The environment now builds from your repo alone.

Next steps​

You now have a working stack in your repo and an environment that builds it. From here, create tasks to build out your real application — the agent works against your code, your standards, and your repo's history.