Web Application Environments

This page shows how to set up a CoderFlow environment for a web application — a backend paired with a browser front end (a framework SPA, or plain HTML/CSS). Every stack follows the same pattern, so this page teaches that pattern once:

• The Stack reference gives the specific commands for each backend (.NET, Node.js, Java, Python, PHP) and each front end (Angular, React, Vue, or plain HTML/CSS).
• The Examples are complete, copy-pasteable walkthroughs for specific combinations.

A setup has two parts. The first — building the app — is ordinary web development and is kept minimal here (the examples show full scaffolds). The second — configuring the CoderFlow environment — is the focus of these docs, and it's nearly identical no matter which stack you choose. Only the values change.

Integrating with IBM i or other systems

A web app here can run standalone, or reach into external systems — query IBM i (DB2/RPG via the sql skill), a SQL Server database, or a host over SSH — through a Connection, which injects the needed credentials and configuration into the task container for you. You don't need any IBM i knowledge to build the app; add an IBM i connection only when it needs IBM i data. (Connections are about the data the app reaches; the serving models below are about how the app is run and viewed — separate choices.)

Choose a serving model

This is the main decision, because it shapes the Application Server configuration and — just as important — how quickly you see your changes while a task is running. Two models start a server inside the task container; the third proxies to a server already running elsewhere.

In a task you view the app the same way regardless of model: open the Testing menu, click Start Server, then open the Launch URL to see the app through CoderFlow's task proxy. What differs is how a new edit reaches that browser tab.

Two-process (live reload)

The front end's dev server runs alongside the backend and proxies API calls to it.

• Seeing changes: the dev server watches your source and rebuilds incrementally, and the task proxy passes through WebSockets — so the browser reloads itself as the agent edits. Edit, then see it; no restart.
• Two ports, and a small proxy that forwards /api to the backend.

This is the smoothest loop for active UI work, and the model the reference grid uses. Prefer it whenever you'll be iterating on the front end.

Single-origin (one process / deploy parity)

One process serves both the app and the API on a single port. The front end is either server-rendered by the backend (PHP, or any templating backend) or a compiled SPA the backend serves as static files — either way, one port, no proxy, no CORS.

• Seeing changes: with a server-rendered front end there's nothing to build — edit and refresh. With a compiled SPA the assets are static, so an edit isn't visible until it's rebuilt (run the build in watch mode writing into the directory the backend serves, then refresh). Either way there's no hot reload.
• One process, one port, no proxy, no CORS — and it mirrors how the app ships to a single host (for example, one Azure App Service).

Best for server-rendered backends, a single process, production parity, or backends whose UI changes rarely. For iterative SPA work, prefer two-process.

Proxy to a running server

The application already runs on a server outside the container — CoderFlow forwards task traffic to it instead of starting anything. You set a Proxy URL instead of a Start Command. The container still holds your source for editing and building, but the live UI comes from the running server.

• Seeing changes: the UI reflects whatever the running server serves; refresh to see its current state.

Use this when the app runs better outside the container than in it — for example a staging or remote dev server, or a legacy app that's hard to containerize. One common case is IBM i green-screen (5250) / Rich Display served by Profound UI Genie, where an Interactive Sessions connection auto-configures the proxy for you — see Setting up an IBM i environment.

	Two-process	Single-origin	Proxy to a running server
App server	Started in the container	Started in the container	Already running elsewhere
Application Server config	Start Command (two processes)	Start Command	Proxy URL
Ports started	Two (dev server + backend)	One (the backend's)	None
Launch URL points at	The dev-server port	The backend port	The proxied server
Seeing front-end edits	Auto-reload (instant)	Refresh (server-rendered) or rebuild (SPA)	Lives on the server
Best for	Fast UI iteration	Server-rendered, one process, deploy parity	Apps already running elsewhere (e.g. IBM i Genie)

The environment pattern

Create the environment from Environments → New Environment in the Web UI. The tabs below are the same for every stack — only the values differ. Look them up in the Stack reference.

Overview

Set Description, Default Agent, Docker Image (a name for this environment's image), and Timezone.

Repositories

Add your repository with Add Repository → With Git Provider (pick the provider, then the repo) or Manual Entry (paste the URL). Set Branch, Path (where the repo is cloned — note it, since the start command and scripts reference it), and Credential Mode. Then choose a Post-clone Action — a per-repository command that runs at image-build time right after this repo is cloned, to install its dependencies (presets include npm ci, dotnet restore, and pip install -r requirements.txt, or pick Custom command for a multi-step install). Each repository has its own, and they're baked into the image. See Git Providers.

Build → Scripts (build hooks)

You don't edit a Dockerfile. CoderFlow generates it from your environment settings — the Build tab has a Dockerfile preview so you can see the result. The hooks that customize the build live on the Build tab, in the Scripts card (marked Advanced), as four tabs: pre-clone, post-clone, setup.sh, and cleanup.sh. Together with each repository's Post-clone Action, that's four places to add steps — three run once at image-build time (in this order), and setup.sh runs later, at container start:

Hook	Where in the Web UI	Runs	Use it for
pre-clone	Build → Scripts → pre-clone	Image build — before any repo is cloned	Install a runtime/SDK missing from the base image (.NET, JDK, PHP). Raw Dockerfile lines.
Post-clone Action	Repositories tab — per repo	Image build — right after that repo clones	Restore that repo's dependencies (npm ci, dotnet restore, …, or Custom command).
post-clone	Build → Scripts → post-clone	Image build — after all repos clone and their actions run	A general build step that spans repos or isn't tied to one. Raw Dockerfile lines.
setup.sh	Build → Scripts → setup.sh	Container start — every task	Steps that must reflect the task's current code, e.g. building the single-origin front end into the folder the backend serves.

The base image already includes Node.js, Git, curl, and Python, so Node.js and Python backends need no pre-clone step; .NET, Java, and PHP install their runtime there (commands in the Stack reference). Use a Post-clone Action per repo for its dependencies, the general post-clone for a build step that spans repos, and setup.sh for anything that must run against the task's live code. (The fourth tab, cleanup.sh, runs when a task container stops.)

Application Server (start command, ports, launch URLs)

This is where the serving model shows up:

• Two-process — add two Ports (the dev server and the backend), a Launch URL at / on the dev-server port (primary), and a Start Command that runs the backend in the background and then the dev server with its proxy.
• Single-origin — add one Port (the backend's), one Launch URL at / on that port (primary), and a Start Command that runs the backend. If the backend renders the UI itself (e.g. PHP), that's all — see the PHP example. If it serves a compiled SPA, also run the SPA build in watch mode in the background, configured to output into the folder the backend serves, so edits rebuild and you just refresh (see the Stack reference).
• Proxy to a running server — leave the Start Command empty and set a Proxy URL to the running server's address, then add a Launch URL for the proxied app. For IBM i green-screen / Rich Display apps, an Interactive Sessions connection sets the proxy, basic auth, and a Genie launch URL automatically — see Setting up an IBM i environment.

Always bind servers to 0.0.0.0 (not localhost) so CoderFlow's task proxy can reach them. Start commands and default ports per stack are in the Stack reference.

Agent Instructions (optional)

On the Agent Instructions tab, under Standard Instructions, enable Screenshot Guidelines. The base image ships Playwright/Chromium, so the agent can open the running app and capture screenshots to verify its own changes.

Tests (optional)

On the Tests tab, add build or smoke commands the Testing menu can run (for example, a front-end build). See Test Definitions.

Build

On the Build tab, click Build Now to bake the image (including any runtime you added via the pre-clone script). When it succeeds, click Save, then Commit & Push to store the configuration.

Run and test

1. Create a task in the environment. CoderFlow launches an isolated container from the built image and runs setup.sh.
2. Open the task and use the Testing menu → Start Server (or Start Server & Launch). CoderFlow runs your Start Command inside the container. See The Testing Menu.
3. Click the Launch URL. The app opens in your browser through CoderFlow's task proxy.
4. Use the in-app feedback widget to screenshot and annotate, and run any commands you defined on the Tests tab.

Next steps

• Stack reference — the per-backend and per-front-end values to plug into the pattern.
• Examples — complete walkthroughs: Node.js + Angular and .NET + Angular (two-process), Node.js + React (two-process, the React/Vite variant), and PHP (single-origin).
• Deploy profiles — run the deploy profile every reference combination ships, to see CoderFlow's deployment flow end to end.
• For IBM i green-screen / Rich Display apps, see Setting up an IBM i environment (proxy).