About
Preconfiguration.com is a project at an early stage. Its engine works: it compiles one spec into the setup files of five platforms, checks the files a repository already has, and proves a setup on a clean machine. A live demo replays it and runs the engine in your browser. The next step is real agents doing real work on the platforms themselves. This site shows where the project stands, gaps included.
Why the Project Exists
AI coding agents now take a task, work on their own and hand back a pull request. Most of them start each task on a fresh machine in the cloud: GitHub Copilot’s cloud agent on a GitHub Actions runner, Cursor’s cloud agents in their own containers, others in dev containers or virtual machines. Whatever the project needs, the right Python, a database, the packages, has to be installed before the agent can build or test anything.
When that machine isn’t ready, the agent guesses. It installs by trial and error, skips the tests it can’t run or hands back code that was never tested. The vendors say so themselves: GitHub warns that an agent left to find and install dependencies by trial and error is slow and unreliable, and Cursor calls environment setup the most important step for getting good work from its cloud agents.
Each platform wants the setup in its own file and format, and most teams use more than one agent. So the same setup gets written three or four times by hand, drifts apart, and breaks where nobody is watching: a job with the wrong name that stops an agent session, a key the platform doesn’t accept, a service nobody starts.

What the Project Is Building
- One spec. A short
preconfig.yaml: the runtimes, the packages, the services, the environment, the setup commands and the ready check. How it works - A compiler.
preconfig buildwrites the file each platform reads: a dev container, GitHub Copilot’s setup workflow, Cursor’s environment, cloud-init and a plain setup script. - A checker.
preconfig checkreads the setup files a repository already has and reports what each platform would reject or ignore, and what has drifted from the spec. - A proof.
preconfig verifyruns the setup and the ready check on a clean machine and names the step that broke. - Later, the team layer. One view of every repository’s agent setup, drift alerts, rules on what agent machines may install, hosted checks and prebuilt machines: the parts companies would pay for. The roadmap
How the Project Works
- Measure, then say it. Every figure on this site was measured on the Alpha, or is marked as an estimate. The scripts that reproduce each number are kept with the Alpha’s source.
- Say what is simulated. The demo’s repositories are samples written for it, and no coding agent ran for this site. The engine is real, and so is every line it printed.
- Plain files, nothing running. Preconfiguration writes the files each platform already reads and then gets out of the way. Nothing of it runs while the agent works.
- Dated knowledge. The platform facts that change most live in one place in the engine, with the date it was last checked against the platform: September 29, 2026 for the Alpha. When a platform changes its format, the engine changes once.
- Small by default. One binary, no daemon, no account, and no dependencies beyond Go’s standard library.
License and Availability
The engine is not public yet. The license will be chosen before the first public release. The plan is a proprietary engine, with an open-source branch under consideration. Until then the prototype is marked “all rights reserved”, and the live demo is the way to see it run.
Questions People Ask
Can I download the engine?
Not yet. It will be available once the license is chosen, around the first public release. The live demo replays real runs of the Alpha and runs the engine in your browser. A demo kit with the Alpha binaries and a sample repository is available on request.
Is the demo real?
The engine is real. Every line in the demo’s terminal is what the Alpha printed on the sample repositories, and the two verify runs were recorded on a clean Ubuntu 24.04 container. The files and findings in its two panels come from the Alpha’s own Go code, compiled for the browser. The repositories are samples written for the demo, and no coding agent ran in it.
Which agents does it support?
Any agent that reads one of its five targets. GitHub Copilot’s cloud agent reads .github/workflows/copilot-setup-steps.yml. Cursor’s cloud agents read .cursor/environment.json. Tools built on the dev container standard, such as GitHub Codespaces and VS Code, read .devcontainer/devcontainer.json. A fresh virtual machine reads cloud-init.yaml. Agents that take a setup script in their settings, such as OpenAI Codex, Claude Code on the web and Google Jules, can run .preconfig/setup.sh. More native targets are Beta work.
Does it replace AGENTS.md or rules files?
No. Those tell an agent how to behave: the conventions, the commands, what not to touch. Preconfiguration handles the machine the agent works on: what is installed, what is running, and whether the tests can pass there. The two sit side by side.
Does it put secrets in the files?
No. preconfig.yaml lists secrets by name only, and a spec is refused when a variable whose name looks like a secret, such as NPM_TOKEN, has its value written in it. Copilot, Cursor and the dev container read them from their platforms’ own secret settings; cloud-init and the setup script take them from the environment they run in. preconfig build says where to set each one.
What does verify need?
Docker, and network access to the package sources the setup uses. It copies the repository into a fresh container read-only, runs the generated setup script and the ready check, and reports each step with its time. Nothing on the machine running verify is changed.
Does it work on macOS or Windows?
The engine compiles for Linux, macOS and Windows, but so far it has run on Linux x86-64 only, verify included. build, check and detect only read and write text files, and verify needs Docker. The generated setups target Ubuntu 24.04, the base of the platforms’ own machines.
Is it open source?
Not decided yet. The license will be chosen before the first public release. The plan is a proprietary engine, with an open-source branch under consideration. Whether the preconfig.yaml format itself is published openly is part of the same decision.
Get in Touch
Teams running coding agents, platform teams who look after many repositories, and anyone with a question or a stack the project should test are welcome to write.