Generate from Repository

Generate from repository turns a repository into a Draft environment for you to review. CoderFlow reads the repository, proposes the configuration you would otherwise enter tab by tab, and leaves what it couldn't settle as Finish setup steps. It is the default in New Environment whenever you give it a repository; Creating Environments walks through the dialog, the fallbacks and Drafts waiting for their configuration.

Nothing is built, nothing is activated and no credentials are copied. You build the Draft's image, check it, and set it to Active yourself.

What CoderFlow reads

CoderFlow takes a shallow copy of the chosen branch, reads the files below and runs nothing from the repository. The values it proposes are the ones the Stack reference documents.

It reads	To propose
package.json scripts and dependencies (Express, Next.js, React, Vite, Angular, Vue)	Install, build and start commands, the dev server and back-end ports, the serving model, and test commands
*.csproj, *.sln, global.json	The .NET SDK install (pre-clone), dotnet restore, and a start command that listens on 0.0.0.0
pom.xml, build.gradle	The JDK install (pre-clone), the build and start commands, and the port
requirements.txt, pyproject.toml	pip install, and a uvicorn or Flask start command
composer.json	The PHP install (pre-clone) and php -S 0.0.0.0:8000
.devcontainer/devcontainer.json, Dockerfile	Runtime features, forwarded ports and post-create commands
compose.yaml or docker-compose.yml database services (PostgreSQL, MySQL, MariaDB, SQL Server), and database drivers	A database the environment needs: a local database in each task container, or a connection to an existing one (see Database)
Migration folders and ORM configuration (for example Prisma)	How a local database is seeded, or the seed commands to run against a connection
.env.example (or .env.sample, .env.template)	Secret names: third-party API keys become secrets; database settings point to the database
.nvmrc, .tool-versions	Runtime versions

Besides the repository root, CoderFlow looks in the first-level folders api, app, backend, client, frontend, server and web, and in the projects a root .NET solution lists. A repository with several parts, such as a front end and an API, gets a combined start command and every port it found. A file it can't inspect (too large, not valid, a symbolic link) is reported as not inspected rather than ignored.

Upload files for Host in CoderFlow puts source files in src/; Choose a folder keeps the folder name, so the app lands in src/<folder>/. When the root and standard component folders have no readable stack, Generate configuration looks for one app in src/, its immediate folders, or a lone top-level folder. The uploaded folder itself must contain the app's manifest, such as package.json, pom.xml, or a .NET project or solution file; a wrapper folder containing only separate component folders is not an app root. When src/ itself holds the manifest, its standard component folders and solution-listed projects belong to that app. It shows the selected folder in the preview and runs generated install, build, start and test commands there. If several folders could hold the app, or an unreadable folder prevents a safe choice, it leaves the choice unresolved. The same detection applies to provider and URL repositories.

What it proposes

The preview in New Environment shows the proposal before anything is created:

• Repository — the repository that was read, and its URL.
• Branch — the branch that was read.
• Stack — the languages and frameworks it recognized.
• Start command — one per part of the app, with the port it listens on and, for a corrected command, the original.
• Ports — every port the app listens on.
• Serving model — how a task serves the app for its browser preview: two processes (a front-end dev server and a back end), a single origin (the back end serves the front end), or a proxy to a running server. The proposal comes first, marked (proposed), with the alternatives it found. See serving models for what each means.
• Database — when the repository uses a database: a choice between a local database in each task container and a connection to an existing database. See Database.
• Tests — test commands from the package scripts or the build tool, with the primary one marked.
• Secrets it will need — names only. Values are never read from the repository.
• Connections it will need — for example a database, unless you choose a local one.
• Warnings — for example a start command it corrected.
• Left for Finish setup — what CoderFlow couldn't settle.

When CoderFlow can't tell part of this, the preview says so instead of guessing, and that part becomes a Finish setup step.

What becomes a Finish setup step

Anything that needs a person, or that CoderFlow couldn't settle from the files, becomes a step in the Draft's Finish setup:

• Add a secret for each name found in .env.example (and in a starter), linking to the Secrets tab with the name filled in.
• Review the local development database, when you chose a local database, or Connect the database when you chose a connection. For PostgreSQL, MySQL, MariaDB and SQL Server the step runs Test connection on a connection named database, and offers to add it if it doesn't exist yet. See Database.
• Connect a Git provider or add a PAT secret, for a repository CoderFlow couldn't read (Create Draft and detect later).
• Build the image, then run a test, so you can see the environment works before setting it to Active.
• Check a port or start command that CoderFlow couldn't tell, and make the server listen on 0.0.0.0 when its code binds 127.0.0.1.

The last step of a generated Draft is Run a first task. Once its image is built, choose Start the first task to open New Task with Get to know this repository applied. The template ships with CoderFlow and asks the agent to summarize the repository, run its build and tests, start the app and capture a screenshot, without changing files. The step's check completes when a task from that template in this environment completes successfully. Review the actual evidence yourself; completion alone does not prove the build and tests passed. See the setup guide's first task for the separate First verified task readiness rule.

A Draft whose configuration is still to be generated has its own steps instead: Upload the source code for a repository hosted in CoderFlow, Give CoderFlow access to a repository it couldn't read, and Generate the environment, which offers Generate configuration.

Steps that check themselves show Done, Not done yet or Can't tell; see Finish setup.

Web app and API defaults

For a web app or API, the proposal also sets these defaults:

• Screenshot Guidelines on. The Screenshot Guidelines standard instruction is turned on, so task agents attach screenshots of the running app as evidence.
• Secrets from .env.example. Third-party API keys named in .env.example become secrets exposed to tasks as environment variables of the same name. Their values are added in Finish setup.
• 127.0.0.1 flagged. A start command that listens on 127.0.0.1 (or localhost) only is flagged: a task's browser preview and the Launch URL reach the app only when it listens on 0.0.0.0. When the tool takes a host option (Vite, Angular, uvicorn and so on), CoderFlow proposes the corrected command, and the preview shows it beside the original. When the address is set in the code, a Finish setup step asks you to change it.
• Spring Boot on port 8081. Port 8080 is the in-browser VS Code in task containers, so a Spring Boot app that would listen on 8080 is started on 8081 (--server.port=8081) instead. Another app on 8080 is flagged so you can move it.

Database

When the repository uses a database, the preview has a Database row with up to two options:

• A local database in each task container — the default when CoderFlow can propose one. The row names the server and version it would install and the memory it adds, for example "PostgreSQL 16, about 50–100 MB of memory when idle".
• Connect to an existing database — a development or test database that already runs somewhere your CoderFlow server can reach.

The preview lists the database under Connections it will need only while Connect to an existing database is selected.

	A local database in each task container	Connect to an existing database
What the Draft gets	The server's install in the pre-clone instructions, after the runtimes; a setup.sh that starts the database and runs the known seed steps when a task container starts; a Review the local development database step in Finish setup; and a Local database section in the environment's AGENTS.md.	A Connect the database step in Finish setup that runs Test connection on a connection named database. Nothing is installed.
What you do next	Review the version and the seed steps, then build the image.	Add the connection on the Connections tab (the Database card, with the engine the step names), then test it. See Database connections.
Data	Throwaway: each task container starts with a fresh database.	Whatever the database you connect holds.
Credentials	None. The database listens on 127.0.0.1 only and has no password.	The connection's user and password, which you enter. CoderFlow never copies them from the repository.
Memory	Added to every task container: approximately 50–100 MB idle for PostgreSQL and 80–160 MB for MariaDB, more under load.	None in the task container.

When the repository uses more than one kind of database, each kind gets its own step and connection name instead of database: database-postgres for PostgreSQL, database-mysql for MySQL and MariaDB, and database-sqlserver for SQL Server.

A local database is offered when CoderFlow finds one PostgreSQL, MySQL or MariaDB database together with a Compose database service, migrations or a dump. Otherwise the row has only Connect to an existing database, with the reason: for example SQL Server, more than one database engine, or a repository CoderFlow couldn't fully inspect. For MySQL, the local server is MariaDB, which is not an exact match for a MySQL version. Development databases describes what is installed, how the database starts and is seeded, the status file to check, and the memory figures.

When CoderFlow can't tell whether more seeding is needed, for example because a file wasn't inspected or migrations run when the app starts, the row says so. It never reports that as nothing to seed.

Nothing here builds the image, sets the Draft to Active or creates a connection or a credential. That stays with you.

Several repositories

An environment can hold up to five repositories, such as a separate front end and API. With Select from provider or Enter URL manually, click Add another repository for each one after the first, and give each its own branch (blank reads its default branch). Host in CoderFlow takes a single repository.

CoderFlow reads each repository with its own access, as it reads a single one, and detects each separately. Each repository gets its own folder in the task container, named after the repository (with a number added if two names are the same). The preview then shows:

• Repositories — each repository with its branch, its folder and what CoderFlow found: Read, Partly read, or Can't tell when it couldn't fully inspect it. What a repository that wasn't fully inspected needs becomes a Finish setup step.
• Combined start command — the one command a task runs to start every part.
• Ports and Launch URL — every port the parts listen on, and the URL the browser preview opens.
• Warnings and Left for Finish setup — each item names its repository, for example two parts on the same port, repositories asking for different versions of a runtime, or a front end whose proxy couldn't be matched to one back end.

A local database is offered only when everything CoderFlow found about the database, its engine and its seed steps, is in one repository, and every repository, that one included, was fully inspected. It is then set up for that repository's folder, and the Database row names the repository. When the database's files are spread over more than one repository, or any repository shows Can't tell, the row has only Connect to an existing database, and the seed commands in the Finish setup step each name their own repository's folder.

The same repository and branch can't be listed twice. If CoderFlow can't read one of the repositories, nothing is created: the preview names that repository (for example "Repository 2 (acme/orders-api)") and offers the same choices as for one repository, except Create Draft and detect later, which takes a single repository. Create without generating uses only the first repository; add the others on the Repos tab.

Many repositories at once

To set up several repositories as separate environments, choose Select from provider in New Environment and click Generate several Drafts (offered only to people who can list the server's Git providers; see Permissions). In the dialog:

1. Choose the Git Provider and the Credential Mode, then use Find repositories to tick up to ten repositories. Each is read from its default branch.
2. Under Drafts to generate, check each environment name. Each is suggested from its repository's name and can be changed; the names must be different.
3. Choose the Default Agent for every Draft, and optionally a Starter.
4. Tick Build each Draft after it's created only if you want each new Draft's image built straight away. It is off by default, and offered only to people who can build environments. Each Draft you may build is added to the Build Images queue once all the Drafts are generated; the dialog then says Queued for build, which means the build was queued, not that it succeeded. Its result shows on the Draft's Build tab.
5. Click Generate N Drafts.

Each repository that uses a database gets the default Database choice: a local database when CoderFlow can propose one, otherwise a connection. To choose per repository, generate that Draft on its own.

The dialog then follows the Drafts one by one: Waiting, Generating…, Draft created (with a link to open it), or Not created with the reason. A repository that fails doesn't stop the others, and leaves no Draft behind. Each new environment is a Draft, visible only to the people who manage it, and nothing is built unless you ticked Build each Draft after it's created.

Closing the dialog doesn't stop the Drafts being generated. If CoderFlow doesn't answer when you start them, the button becomes Try again; reopening the dialog keeps your choices, and Try again repeats the same request, so no Draft is generated twice. If the server restarts while they are being generated, the dialog can't tell how they went and says so: check the Environments list for the Drafts that were created.

Starters

Choose a Starter to begin from your organization's conventions: default agent and models, instructions, skills, templates, test conventions and deployment profiles saved from another environment with Save as starter. What CoderFlow finds in the repository is layered on top. See Starters.

Permissions

Generating needs environments:manage on any environment, and the ability to manage the new Draft: Server Admins, or roles that grant environments:manage on all environments. New Environment makes it the default for Server Admins, and offers it to people who manage every environment they can see. Add another repository is offered to the same people. Generate several Drafts also needs access to the server's Git providers (settings:git-providers, which Server Admins have), because it lists their repositories; without it, the button isn't offered. Generating the configuration of an existing Draft needs environments:manage on it.

After generating

• To have an agent finish the Draft's setup, building it, starting the app and running its tests within budgets you set, use Configure this environment.
• When a repository changes later, for example a new runtime version in global.json or .nvmrc, use Check repositories for changes on the environment. It never suggests adding a local database: an environment keeps the Database choice it was generated with. To change it, see Switching to a connection.