Installation and first access

Enterprise’s first delivery target is self-hosted, guided early testing. The server runs in Linux containers; you use its Console in a desktop browser. Studio draft execution currently needs a separate Windows runner.

What can I install today?

Choose your setup path for the steps that apply to you. You can run the careers exercise locally before preparing a server.

The 0.1.0-alpha.1 release has public Docker images and Windows packages. Download the packages, image references and tutorial files. A complete self-service installation bundle is still in preparation. The containers are components, not a configured installation. There is no hosted signup or public one-command Enterprise setup on this site.

Already have a Console URL? Continue with first access.
Evaluating with an operator? Use the handoff below to agree on a prepared installation.
Only have a Docker Hub image? Read the image guide. It includes a safe, database-free way to inspect the migration image.

The current developer setup builds from source and contains synthetic local identity settings. It is not a general deployment template for a public server. Access to images does not imply access to the private source repository.

Requirements for the guided evaluation

Part	Requirement
Server	Docker with Linux `amd64` containers and Compose; PostgreSQL, identity, HTTPS and persistent storage configured by the operator.
Studio browser	A desktop browser with a viewport at least 1600 pixels wide. Studio has been reviewed at 1600x900 and 1920x1080.
Draft execution	A Windows x64 machine and the matching self-contained draft-runner package. Headed browser tests need an interactive desktop and WebView2.
Identity	A sign-in account authorized for the exact evaluation tenant and workspace.
Test material	An isolated draft with the synthetic first-draft source and its schemas.
AI	Optional. The first exercise uses no provider, API key or inference calls.

The published container platform does not establish ARM64 support or Linux headed-browser execution. This alpha has no published minimum RAM or throughput guarantee; size the chosen evaluation with its operator.

Operator preparation and handoff

Prepare one matching set of API, Console, migration and Windows packages. Avoid mixing builds just because their version labels look alike; record the image digests and package checksums supplied with the candidate.

Configure persistent database and artifact storage, the identity provider, exact application origins and HTTPS certificates.
Review the migration plan from the selected image, then apply it to the intended database using the installation’s controlled credentials.
Start API and Console with their identity configuration. Test a real login and exact workspace access; a healthy container alone does not prove either.
Connect the separate draft runner with its own credential, TLS trust and permitted workspace scope.
Prepare the synthetic tutorial source. Confirm that its saved code returns the expected record.
Give the tester the Console URL, sign-in method, workspace and draft names, build identifier and a support contact.

Keep the configuration and package inventory with your installation record. Use your own configured identity provider when exposing the installation beyond the development machine.

First access

Open the Console URL provided by your operator. Confirm the expected hostname and trusted HTTPS connection.
Sign in and select your assigned workspace.
Open Workspace Studio, then the assigned draft and source implementation.
Select Test draft and confirm the runner is available. Use Refresh after the operator has restored a disconnected runner.
Complete edit, test and correct a draft.

Success means you can run the saved source and recognize its returned record. A login screen, green health endpoint or container marked running is an earlier checkpoint.

If a step fails, use troubleshooting before changing the setup. See alpha availability for current packages and access.