Improve Docker DX

[elprans]

Currently, the CLI classifies instances as "local" (i.e owned and managed by the CLI directly), "cloud" (Gel Cloud instances, also can be managed by the CLI) and "remote" (an arbitrary remote Gel instance that can only be connected to). Many devs are accustomed to using Docker (and Docker Compose specifically) for local development, and currently the CLI handles those instances as "remote", which introduces unnecessary friction especially around authentication.

Here's what I propose we should do:

1. Teach the CLI to read docker-compose.yml and detect if it contains a gel container. The exact detection mechanism is TBD, but a consideration should be given to custom images based on geldata/gel.
2. If a docker-compose with a gel container is found, gel project init should ask if the user wants to use that as the instance for the project, and if so, link the project to the container.
3. For convenience edgedb instance start/stop/restart should alias to docker compose start/stop/restart <gel-service-in-compose>.
4. edgedb instance upgrade should work, but most of the work should be done in the Docker image entrypoint (I already have a PoC for this for a dump/restore flow).

[tiberiusferreira]

Mentioning in case it's helpful, but I think this is a bit overkill (parsing docker yml and aliasing docker compose).

If we can easily have the Gel CLI connect to a remote instance by providing it an ip + port + credentials, which is already the case it's all good CLI-wise.

The main issue with 6.0 release seems to be the expectation of the UI "just working" when you try to login to it by going to the container UI address+port via browser (saw 2 other people asking why it was not working in discord a new one here.

If the docs were a bit better around which URL to use (http vs https), which env vars to set in the compose file (EDGEDB_SERVER_ADMIN_UI, EDGEDB_SERVER_SECURITY, SSL related env vars etc) and which user+password to use it would mostly solve it.

This would also not create more differences between the local and remote workflows.

[mmastrac]

We’ve shipped the first version of improved Docker developer experience in the gel CLI, now available in the latest nightly builds.

How It Works

Docker is used as a fallback connection method if no other connection parameters are provided. This means that if a host, port, credentials file, DSN, or other parameters are specified via command-line arguments or environment variables, implicit Docker credentials will not be used.

New Connection Options

• --docker: Explicitly use Docker for authentication, even if other parameters are provided.
• --container: Optionally specify the container name. This can be a standalone container or part of a Docker Compose project.

Automatic Detection and Authentication

If no credentials are found, Gel attempts to detect if the current directory belongs to a Docker Compose project. If so:

1. It searches for a running container with the service name gel or edgedb.
2. It extracts the server’s command-line arguments and locates the private JWT key.
3. This JWT key is used to generate a connection credential.
4. The resolved host and port are determined based on the container’s port bindings (e.g., internal port 5656 bound to localhost:1234).

Authentication Flow

• gel ui: The generated JWT key is passed as a query-string parameter to pre-authenticate the user in the Gel UI.
• gel and gel query (Interactive REPL & Non-interactive query commands): The secret key is used as the connection credential.
• gel instance link: When called without connection parameters in a Docker Compose project, the secret key is stored in the project credentials.

Important Notes

The Docker-based instance must allow JWT-authorized connections for operations such as HTTP UI access or Gel binary protocol interactions. This is enabled by default in the Gel container. However, if the user modifies the auth settings, they may encounter connection issues.

( @1st1 / @scotttrinh )