Admin guide¶
Most people never run a gdc server: the terminal app runs everything it needs on its own. You need this section when you want to share one gdc instance across people or machines, run it on a remote host, or expose it beyond your own machine.
When you need a server¶
| Situation | What to do |
|---|---|
| Just using gdc yourself, locally | Nothing — run gdc-tui. |
| The terminal app connecting to gdc on another host | Run a server; connect with gdc-tui --bind. |
| Several people or machines sharing one instance | Run a server, secure it with TLS. |
| A read-only view of session history over HTTP | Use the HTTP API. |
| Multiple hosts collaborating on tasks | Set up a swarm (experimental). |
What a server is¶
gdc serve starts gdc as a long-running background process. It:
- powers remote terminal-app clients
that connect with
--bind, - exposes a small read-only HTTP API for inspecting session history, and
- can host swarm roles when you're running a distributed setup.
By default it binds to loopback only (127.0.0.1), so nothing is exposed
off the machine until you decide to.
In this section¶
- Running a server — start,
bind, and tune
gdc serve. - TLS — encrypt connections with your own certificate, a self-signed one, or automatic certificates.
- HTTP API — the read-only endpoints for session inspection.
- Security — hardening, key handling, and safe exposure.
- Swarm — connect multiple hosts (experimental).
Before you expose anything¶
Loopback is the safe default for a reason
A gdc server drives an agent that can run commands and edit files. Never bind it to a public address without putting authentication and transport security in front of it. Read Security first.