FIELD NOTES / GETTING STARTED
Run coding agents on your own infrastructure: what you need before you start
You want to start a coding task, close your laptop, and review the result later. Before moving that task to your own infrastructure, decide where it will run, how the agent will authenticate, and what evidence you need back.
Open AgentHub gives coding agents isolated workspaces on your Kubernetes cluster. It is a self-hosted tool, so running the environment is part of the job. Here is how to make the first experiment small enough to learn from.
Start with one task you can check
Choose a repository you control whose tests run with the tools available in the session image. A small Node project is a useful starting point: verify its required Node version and dependency-install instructions first. Do not assume Docker, .NET or another toolchain is already installed. For example:
Inspect this repository's test instructions. Run the documented test command. Write a Markdown report containing the command, actual result, and any blocker. Do not change project files or push commits.
This is a proposed trial, not a claim that every repository's tests will pass. If dependencies are missing, a useful result explains that failure. The laptop gets a break; the acceptance criteria do not.
Check the report against the actual session output. A confident summary is not a substitute for the command and result.
Make sure there is somewhere to run it
AgentHub uses Kubernetes for its agent workspaces. If you already operate a cluster, follow the Helm installation guide. If you do not, the project's all-in-one installer offers a single-node starting point. The guide recommends 4 vCPU and 6 GB RAM as an initial reference; check current requirements and size for the work you intend to run.
Do not size the machine from the dashboard alone. Agent workloads need resources too: installing dependencies, running browsers, compiling applications and recording a demo can have very different demands. Start with one session and observe its resource use before increasing concurrency. This article makes no user-capacity or speed promise.
Configure web access and provider login separately
From Open AgentHub 1.5.0, an installation without OIDC requires a shared admin API key. This is one shared identity, not separate user accounts. Use HTTPS when exposing the service, and configure OIDC when you need individual identities. Earlier versions defaulted to an unauthenticated development mode without OIDC; follow the current upgrade instructions for existing installations.
Authenticating Claude or another coding provider is a separate step. Follow the current provider-login instructions in an Interactive session, or configure the supported API-key option. A provider subscription or API key does not automatically appear just because the hub is running.
Keep tokens out of prompts, screenshots, example projects and published reports. Complete interactive login yourself when the provider asks for it.
Plan persistence before you trust it
The all-in-one quickstart configures persistent Postgres and S3-compatible object storage by default. Disabling object storage is possible but not recommended. When installing with Helm yourself, follow the storage configuration instructions. The installation guide strongly recommends object storage for session history, resume and persistent artifacts. Without the appropriate storage configuration, a disposable agent pod is a poor place to keep the only copy of important work.
For the first task, ask the agent to upload the report to Files, inspect it there and download the original. Transfer repository changes through your normal Git workflow. The separate session-transfer helpers copy conversation history; they do not copy your repository, uncommitted project files or attachments.
Count the costs you still own
The AGPL core does not require a licence key. Your infrastructure and model-provider usage can still cost money. You also own maintenance, updates and the access controls appropriate to your environment.
Before exposing an installation to other people, configure authentication using the installation guide. A local first look and a shared team service have different operational needs.
Decide whether the first run helped
Ask four questions after the experiment:
- Did a real agent session start and finish, or did it report a clear blocker?
- Can you verify the result from commands and output?
- Can you retrieve the report and any work you need to keep?
- Would you choose this setup again for the same kind of task?
A blocked installation is useful feedback too. Record the operating environment and error, with secrets removed, rather than claiming success from a screenshot of the dashboard.