Choose your next step
GroundControl is installed. What next?
Go from a claimed instance to one understood workload and a verified agent connection.
You know your active host, have chosen an existing or new application, and can verify the next step.
On this page
First, know what installation completed
The launcher starts GroundControl privately, creates persistent storage and connects the local Docker workspace or destination Linux server. Claim establishes your administrator account. You do not need to add that same host again using SSH.
After claim, desktop onboarding verifies private local access. On a Linux server, you can publish a stable HTTPS origin for remote MCP clients or keep it private while evaluating. On completion, GroundControl probes the host and shows its findings.
| Already done | Still your decision |
|---|---|
| GroundControl is running and claimed | Which existing applications to enroll, or which new application to deploy |
| The local host is connected | Whether to add another remote server |
| Onboarding can inspect host state | Whether the detected paths and proxy match your actual setup |
| OAuth and MCP are built into the instance | Which client gets access, to which workloads and capabilities |
Review the onboarding scan
The scan looks for the operating system, Docker, containers, reverse proxy and existing application folders. It can ask you to clarify an unknown proxy, a missing proxy configuration path, containers without Compose labels, or a Compose project without running containers.
Answer from your real setup. A detected file or route is an observation, not a health result. If your app lives outside the configured discovery paths, it may appear in the broader onboarding findings but be missing from the deployment inventory. Adjust Settings → Layout and rescan.
You recognize the active server and can identify where one application lives. If the probe failed, resolve the host connection before treating an empty list as an empty server.
Choose your first application
Start in Projects → Add project and pick a folder or GitHub repository. In that project, choose Add deploymentto connect an existing workload or launch a new instance. Theprojects guide explains each path.
Know where to go in the product
| Workspace | Use it for |
|---|---|
| Overview | Orientation to the selected host, its condition and the applications running there. |
| Deployments | Scan candidates, enroll a workload, and open its Manage, Deploy, Environment and Configure controls. |
| Projects | Add an application from a folder or GitHub and organize its deployment instances by host and environment. |
| Runtime | Inspect containers and their state when you need the lower-level picture. |
| Templates | Choose, validate, configure, review and deploy a new workload. |
| Intelligence / Alerts | Follow failures and investigate the runtime and public-route evidence. |
| Agents | Copy the MCP endpoint and review or revoke authorized clients. |
| Settings → VPS / Layout | Manage host connections and confirm where GroundControl looks for workloads. |
| Terminal | Use the human operator shell for work that requires direct host access. |
Finish with a small, observable success
Open your enrolled application, confirm its source and containers, and record the real public URL. Connect your agent after you can identify that workload. Start with a read-only request:
Use GroundControl to list my available deployments. Inspect the one I select and check its runtime and public health. Show what you verified and what is still unknown. Do not change anything.The agent calls GroundControl, sees only granted deployments, and returns actual tool evidence. A public check may be skipped when no public URL exists; that is not proof that the customer endpoint works.
Move to a controlled redeploy when the identity and recovery plan are understood. Enable merge automation only after its managed-mode and repository requirements are met.