FerryDocs
ArchitectureOverview

The API

An API call checks who you are, writes to the store, and puts long work in a queue.

Edit on GitHub

Each /api/v1 request goes through three steps:

  1. The authentication check. It accepts an or the session cookie of the dashboard. See the security model.
  2. A handler. It validates the input and writes to the .
  3. The engine. For all work on containers, the handler calls the .

Long work goes in a queue

The handler does not wait for a . It answers 202 with the deploy in the queue. The client then follows the log of the deploy as a stream.

After each write, the API signals the . See the API overview. Thus the dashboard updates immediately.

The crates

CrateContents
ferry-apiThe axum router: REST, authentication (the account, its sessions and API tokens), , webhooks and blueprints. Also the OpenAPI document, Swagger UI and the web client from web/dist.
ferry-cliThe program ferry: the command-line client. It talks only to the REST API.
ferry-scmThe git providers (GitHub, GitLab): authorization in the browser, tokens and the list of repositories.

The proxy

The proxy sends each request to an instance, and it reads only the route table to do it.

The engine

The engine is the part of ferryd that runs deploys, repairs containers and starts scheduled work.

On this page

Long work goes in a queueThe crates