Concepts & principles
The GroundControl approach
Understand the product, the things it manages, and how an agent gets a useful but bounded role in operating them.
A clear model of hosts, projects, deployments, services, agent grants and recorded operations.
On this page
Help the conversation follow through
You should be able to ask an agent what is happening with your application and have it work from real state. GroundControl provides that connection. It runs on infrastructure you own, understands the selected workload, and exposes specific operations through MCP and OAuth.
The operator establishes access and approves the workload scope. Within that grant, an agent can inspect deployments, check health, read logs and request supported actions without asking you to supply infrastructure credentials at each step. Client confirmations and expired grants still need attention.
Start on your computer with Docker, or on a Linux server with the applications you already operate. GroundControl also has human controls for runtime, logs, environment, proxy configuration and terminal access. You can begin using those before connecting an external agent.
Know what you are looking at
An OAuth grant selects the deployment. Operations act on that identity and record their results.
| Term | What it means in GroundControl |
|---|---|
| Host / VPS | The server being inspected or operated. The canonical installer connects its own host; remote servers are explicit connections. |
| Project | Your application or product, with folder or GitHub sources and deployment instances. Organizing deployments preserves their files and runtime. |
| Deployment | An instance of an application on a particular host and environment, with a Compose or container runtime identity, public URL and recorded releases where available. |
| Service / container | A component of a deployment, such as web, API, PostgreSQL or Redis. A single deployment can have several containers. |
| Public route | The customer address and its proxy/upstream relationship. Its reachability is checked separately from container state. |
| Agent grant | The OAuth client’s approved capabilities and selected deployments. Enrollment alone creates no external-agent permission. |
| Operation | A request with an ID, progress, attempts, result and evidence. Use that ID to follow durable agent work. |
| Release | A recorded deployment execution with source/runtime identity and verification evidence where available. |
A project group in GroundControl is also different from a Docker Compose project name. The former organizes applications in the UI; the latter identifies a stack in Docker.
Make each boundary explicit
- Discover: find evidence on the active host. A candidate is a finding to inspect.
- Enrol: register the workload you want GroundControl to track, preserving its location.
- Configure: confirm source, runtime, environment and the public address. Management mode affects which automation is eligible.
- Authorize: decide which external agent can use which capabilities on which enrolled workloads.
- Operate and verify: follow the specific request, inspect its evidence, and check the public result.
Tracking mode is not a universal read-only security boundary. Source deployment and merge automation require managed mode, but other available actions have their own checks. OAuth scopes and deployment selection determine the external client’s permissions.
The principles behind the controls
Begin with the infrastructure you own.
Discover existing applications in place. The operator chooses enrollment and keeps control of the instance, credentials and workload scope.
Ask for an outcome and retain the evidence.
The agent requests a supported operation. GroundControl owns execution and records the result. A chat timeout should lead back to the same operation ID.
Verify what the customer can reach.
Container state, health checks and public HTTP results answer different questions. A process running successfully does not establish that an entire customer journey works.
Earn automation one workload at a time.
Establish identity, test a manual deployment, then enable the specific automation you intend. A model’s confidence does not expand its grant.
Where intelligence and Daytona fit
Loop is GroundControl’s intelligence and recovery engine. Its current workspace relates host, runtime and public-route evidence, records changes and supports investigations. The direction is to understand failures and prepare the least disruptive recovery with evidence.
Daytona is an optional, early-access path for reproducing eligible code or configuration failures in isolation. Production still runs on your VPS. A merge-triggered source deployment is a separate capability from autonomous incident recovery.
Authenticated browser journeys, durable intelligence memory across process restarts and generally enabled autonomous recovery are not established by the current public evidence. The evidence guide states what has actually been checked.
Put the model to work
Start with installation if you have not installed GroundControl. If your instance is already claimed, follow After installation to choose your first workload.