Preprovisioning Pools
C3 Code builds the environment behind an application or a workspace in minutes, and a developer waits through that build each time they create one. Preprovisioning keeps a set of fully built copies ready ahead of demand, so C3 Code hands one over in seconds and rebuilds the set in the background. As an administrator, you run this from the Preprovisioning Pools page: read how full each pool is and whether it is keeping up, create and size the pools you want kept ready, keep them healthy, and clear stale copies after an upgrade.
C3 Code keeps two kinds of pool. A Template Pool keeps ready applications built from a template, for the moment someone creates a new application from that template. An Application Pool keeps ready workspaces for one Git-connected application, for the moment someone adds a workspace to it. A scheduled job called the reconciler tops each pool back up to its target size and clears copies that have sat too long. When someone creates an application or a workspace, C3 Code claims a ready copy from the matching pool and transfers it to them. If no ready copy is waiting, creation falls back to the normal build, with no difference the developer notices.
Open the Preprovisioning Pools page
Open the Admin section from the left navigation and select Preprovisioning. The page is available to administrators.
Read pool health
The page opens with the reconciler's status, five summary figures, and a card for every pool, followed by the individual entries and a record of past claims.
Confirm the reconciler is running
The pools only stay full while the reconciler runs, so start here. The Reconciler Status card shows Enabled when the job is active, names the schedule it runs on, and reports its last run, next run, and last status. A recent Last run and a Status of COMPLETED mean the pools are being maintained. Select View run history to see every past run, newest first, with the error attached to any run that failed.
If the card reports that the reconciler is not configured, the pools will not refill until a platform administrator initializes it.
Read the summary figures
The five figures across the top tell you, at a glance, whether preprovisioning is paying off:
- Claims Today: copies handed to developers so far today.
- Total Claimed: copies handed to developers across all pools since preprovisioning began.
- Avg Provision Time: how long, on average, a copy takes to build and become ready.
- Avg Claim Time: the average time C3 Code takes to hand a ready application or workspace to the developer creating one. This covers only the hand-over, so the developer skips the build that the Avg Provision Time above measures.
- Active Errors: copies currently in an error state across all pools. Anything above zero is worth investigating.
Read a pool card
Each pool has a card under Pools, labelled TEMPLATE or APPLICATION with the template or application it serves. The card leads with Fill Level: the number of ready copies against the target you set, shown as a count and a percentage. A pool below its target stands out at a glance. Four counts break down the copies behind that figure:
- Ready: copies built and waiting to be claimed right now.
- Prov.: copies still building.
- Error: copies that failed to build.
- Claimed: copies handed to developers from this pool so far.
The card also shows the pool's Max age and an edit control for changing its settings.
Inspect individual entries
Below the cards, Template Entries and Application Entries list every copy in each pool, so you can trace a stuck or failed one. Each row carries its Status in the pool lifecycle, its Workspace State, and its SNE State — the state of the single-node environment, the isolated C3 server behind the copy. The remaining columns report the copy's Age, how long it took to provision, when it became ready, and any error. Open the Actions menu on a row to remove that copy.
A copy moves through a fixed set of states, shown in the Status column:
- PROVISIONING: the copy is building.
- READY: built and waiting in the pool.
- CLAIMING: being handed to a developer.
- CLAIMED: transferred to a developer and no longer in the pool.
- ERROR: the copy failed and needs attention.
- EXPIRED: too old, and cleared by the reconciler.
Review claim history
The Claim History section is the record of every claim across all pools. Read it to confirm developers are drawing on the pools you enabled, and to spot a pool that builds copies nobody claims.
Each row is one claim:
- Type: whether the claimed copy was a workspace or an application. A workspace comes from an Application Pool, an application from a Template Pool.
- Name: the name the developer gave the claimed application or workspace.
- Claimed By: the developer who claimed it.
- Claimed At: when the claim happened.
- Time in Pool: how long the copy waited as ready before it was claimed.
- Provision Duration: how long the copy took to build.
- Claim Duration: how long the hand-over to the developer took.
Search by name or user, or filter by type, to find a specific claim.
Create or size a pool
Select Add Pool to open the Create Pool dialog, or the edit control on a pool card to change an existing pool. Four settings are common to both kinds of pool:
- Pool Size: the number of ready copies to keep waiting. This is the target the reconciler fills toward.
- Max Age (hours): how long a ready copy may sit before the reconciler expires it and builds a fresh one, which keeps a warm copy from drifting out of date. Leave it blank to use the default — 48 hours for a Template Pool, 24 hours for an Application Pool.
- Max Errored Entries: how many failed copies a pool tolerates before it pauses new builds until you clear them. This keeps a systemic failure from piling up broken copies. Leave it blank to use the default of 5.
- Enabled: whether the reconciler actively maintains this pool. A pool starts disabled, so C3 Code keeps nothing ready until you enable one.
Create a Template Pool
A Template Pool keeps ready applications built from one template. Select Template Pool, choose the Template to keep warm, then set the pool size and the options above.
Create an Application Pool
An Application Pool keeps ready workspaces for one Git-connected application. Select Application Pool, choose the Application, and provide a Git Token. C3 Code uses the token to clone the application's repository when it builds each ready workspace in the background, and stores it as a secret on the application. The remaining settings match a Template Pool.
Size a pool to demand
Size each pool to how often people claim from it, not to how many users you have. A template nobody starts from needs nothing kept ready. The pool cards give you the signals to tune against:
- Fill Level below the target means the reconciler has not refilled the pool to its target yet. Claims still succeed while copies remain, so the wait returns only once the pool empties and the next developer falls back to a full build. Raise the pool size or investigate slow provisioning.
- A full pool with few claims means ready copies are sitting idle and holding compute. Lower the pool size.
- A rising Error count drains a pool quietly, with no other symptom until people start waiting.
Keeping copies ready holds compute while they wait, so a pool is a trade between a shorter wait and a higher steady cost. For the compute each workspace holds, see Application Settings.
Recover from provisioning errors
When a pool's Error count reaches its Max Errored Entries, the reconciler stops building new copies for that pool, and the card reports the halt. This keeps a repeating failure from piling up broken copies, and provisioning resumes once you clear the failed copies.
Clear a failed copy from the Actions menu on its row in the entries table. Removing it terminates its underlying environment, and the reconciler builds a fresh replacement on its next run if the pool is enabled and below its target. The reconciler also clears errored copies on its own after a short time, so a pool recovers without intervention once the underlying problem is fixed.
Refresh pools after an upgrade
After a platform upgrade, the copies already waiting in the pools may still run the configuration from before the upgrade. Select Invalidate All to drain them: it terminates every unclaimed copy across all pools and leaves the copies already claimed by developers untouched. Type INVALIDATE to confirm. The reconciler then repopulates the pools with fresh copies on its normal schedule. Run this once after each upgrade.