You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 16, 2026. It is now read-only.
Follow-up to #31. This is the umbrella: the motivation, the settled decisions and the shape of the whole thing. The work is in the child issues listed under How this is split, each of which is finished and closed on its own.
Problem / Motivation
Since #31 the app can run a signed-in user's work inside a container instead of directly on the machine hosting it — but where that happens is decided once, when the server is started, by whoever started it. One engine, one destination, no way to change it without restarting the process, and no way to have more than one place configured at a time. A team with a laptop running Docker, a build box running Podman and two Kubernetes clusters has to pick one of them, permanently. Nor is any of it changeable by the person actually running the installation without going back to the command line, while other settings of the same weight are already editable from Settings.
The unit is wrong too. Where it is switched on, a user gets one long-lived environment shared by everything they do, so work on one repository sits in the same box as everything else they have open, and the box outlives all of it. What people work on is a repository, and there is nothing in the product that knows that.
The container's contents are an administrator's problem as well. What tooling exists inside is whatever the base image happens to carry, so working on a Python repository in an image built for Node means installing the language first, and the tools people reach for constantly — git configured as themselves, a working command line for the forge the repository lives on — are absent unless somebody thought to bake them in.
Underneath all of it is one identity, from one vendor. Sign-in is GitHub-only and mandatory, so an organisation on Microsoft, Google, a directory or its own GitLab either cannot use the product or hands out GitHub accounts to people who have no other reason to own one — and then authenticates to their real platform all over again by hand.
And keeping any of this is currently free only by accident: there is one environment per user, and its home outlives every rebuild, sign-ins and skills included. Break the work into per-project containers built and discarded on their own schedule and it stops being free — every new project and every rebuild becomes another round of signing in and reinstalling. That is worth designing away before it exists rather than after.
Goal
An installation defines named deploy targets from Settings — Docker, Podman or Kubernetes, several at once, including several clusters. A user signs in with whichever provider their organisation uses, creates a project from a git repository link, and gets a dedicated container on the configured target: the code checked out, the languages that repository actually needs installed, git and the right forge tooling already signed in as them, and their own agents, skills and settings already in place. They open as many sessions inside that project as they like and work in any folder in it. The container outlives tabs and sessions and goes away when the project does. An installation that defines no targets keeps working exactly as it does today.
Replacing local operation: an installation with no targets must keep working as it does now.
Any per-user or per-session choice of target.
Scheduling or balancing work across targets automatically.
Running per-user environments and deploy targets side by side as competing placements; where both are configured, the target decides.
Sharing a project, its container or its storage between users.
Enforcing storage quotas — usage is measured and reported, never capped.
Letting users supply arbitrary images or engine settings; what a target offers is an administrative decision.
Moving the app's own server into a cluster, or anything that manages the cluster itself.
Security / Safety Considerations
These cut across the whole feature; each child carries the ones specific to it.
A target definition carries what is needed to reach and command a container engine or a cluster, which is close to full control of the machine behind it. Adding one is a deliberate administrative act, restricted to the installation's owner.
Creating and destroying environments is, today, deliberately not something a browser session can do. This work changes that, and the change deserves to be narrow: a defined set of actions on a defined set of targets, attributable to the account that performed them.
The app starts keeping credentials it has never kept before. Signing in today borrows a user's GitHub access for the moment it reads their account and keeps nothing afterwards; from here it holds repository access and connected-host credentials for as long as the user has an account, and gains the ability to write to their own repositories on their behalf. All of it needs to be explained where it is requested, confined to what it was asked for, and removable.
Each user's persistent storage holds their agent sign-ins, their connected credentials and their tooling indefinitely, and is attached to every container built for them. It needs the same protection as the rest of their data, must be unreachable from anyone else's project, and must be removable when their access is revoked.
One user's project must never be reachable from another's, whichever target it runs on.
Acceptance Criteria
The feature as a whole is done when its children are closed and, end to end:
An installation with no targets configured behaves exactly as it does today — including the per-user environments it may already be using — and nothing here requires, contacts or looks for a container engine of its own.
An administrator can configure several targets from Settings and point the installation at any of them without restarting the server, with what happens to work already running stated rather than discovered.
A user creating a project from a repository link is working in it — code checked out, languages present, git and forge tooling signed in as them, agent ready — without configuring anything by hand.
A user who has signed in once is never asked to sign in or reconfigure again: not in a second project, not after a rebuild, not on a container built from scratch.
Closing sessions, tabs and browsers never destroys a project; deleting the project does.
A user signed in through any enabled provider can do all of the above, with the parts that need repository access clearly marked for those whose provider does not carry it.
Two and three are the pair to watch: a project container without persistent user storage would regress what #31 already gives people, so the storage that outlives a container has to land with projects even though the rest of composition follows.
Decisions
Settled up front, so the questions behind them do not get reopened during implementation.
The container belongs to a project, not to a session or a tab. Sessions live inside it, as many as the user wants, and closing them leaves it alone.
A project is created from a git repository link, any host, or from nothing at all.
A project's container is stopped when idle, reclaimed when idle far longer, and removed when the project is deleted.
The working tree is disposable and re-cloned on every build; the repository is the source of truth.
Uncommitted work is preserved to the repository before any rebuild, and a preservation that cannot be completed holds the rebuild back until the user decides.
A project with no repository is disposable too, since there is nowhere to preserve its work to; the interface says so rather than pretending otherwise.
A user's agents, sign-ins, skills, tooling and settings persist for the user, not the container — set up once, present in every project, never asked again. A project may add its own on top.
What a container contains is derived from the repository, with everything found installed and the user free to change the list before it is built.
The forge tool follows the repository's host — signed in from the user's own sign-in where they signed in on that platform, and connected once by the user where they did not.
git is configured as the user, from the identity their provider reports, with an override that persists.
Storage usage is measured and reported, never enforced. A hard per-user quota cannot be honoured on the storage this product runs on, so it is not promised.
Where a target is configured, it wins over the per-user environments an installation may already be using, and changing the target moves new work rather than existing work.
Placement is an administrative decision — one configured target, no user-facing picker.
How many projects a user may run at once is capped by the administrator, as one global number applied per user. Creating projects is unlimited. At the limit the user is offered a swap and confirms it.
Identities are never merged automatically because two providers report the same email address.
Follow-up to #31. This is the umbrella: the motivation, the settled decisions and the shape of the whole thing. The work is in the child issues listed under How this is split, each of which is finished and closed on its own.
Problem / Motivation
Since #31 the app can run a signed-in user's work inside a container instead of directly on the machine hosting it — but where that happens is decided once, when the server is started, by whoever started it. One engine, one destination, no way to change it without restarting the process, and no way to have more than one place configured at a time. A team with a laptop running Docker, a build box running Podman and two Kubernetes clusters has to pick one of them, permanently. Nor is any of it changeable by the person actually running the installation without going back to the command line, while other settings of the same weight are already editable from Settings.
The unit is wrong too. Where it is switched on, a user gets one long-lived environment shared by everything they do, so work on one repository sits in the same box as everything else they have open, and the box outlives all of it. What people work on is a repository, and there is nothing in the product that knows that.
The container's contents are an administrator's problem as well. What tooling exists inside is whatever the base image happens to carry, so working on a Python repository in an image built for Node means installing the language first, and the tools people reach for constantly — git configured as themselves, a working command line for the forge the repository lives on — are absent unless somebody thought to bake them in.
Underneath all of it is one identity, from one vendor. Sign-in is GitHub-only and mandatory, so an organisation on Microsoft, Google, a directory or its own GitLab either cannot use the product or hands out GitHub accounts to people who have no other reason to own one — and then authenticates to their real platform all over again by hand.
And keeping any of this is currently free only by accident: there is one environment per user, and its home outlives every rebuild, sign-ins and skills included. Break the work into per-project containers built and discarded on their own schedule and it stops being free — every new project and every rebuild becomes another round of signing in and reinstalling. That is worth designing away before it exists rather than after.
Goal
An installation defines named deploy targets from Settings — Docker, Podman or Kubernetes, several at once, including several clusters. A user signs in with whichever provider their organisation uses, creates a project from a git repository link, and gets a dedicated container on the configured target: the code checked out, the languages that repository actually needs installed, git and the right forge tooling already signed in as them, and their own agents, skills and settings already in place. They open as many sessions inside that project as they like and work in any folder in it. The container outlives tabs and sessions and goes away when the project does. An installation that defines no targets keeps working exactly as it does today.
How this is split
Non-goals
Security / Safety Considerations
These cut across the whole feature; each child carries the ones specific to it.
Acceptance Criteria
The feature as a whole is done when its children are closed and, end to end:
Suggested Phasing
Each phase closes one child.
Two and three are the pair to watch: a project container without persistent user storage would regress what #31 already gives people, so the storage that outlives a container has to land with projects even though the rest of composition follows.
Decisions
Settled up front, so the questions behind them do not get reopened during implementation.