Self-hosted build and run server

It will be optional. You will write, check, build and run projects with the ael command alone, and the programs you build will never need the server to start.

What it will do

• Jobs. Run checks, builds, tests, evaluations and runs as jobs. Each job will work on a fixed snapshot of your source, prompts, configuration and locked packages, so an edit made afterwards will never change a job in progress.
• Output that survives disconnects. Reconnect to a job and read what you missed. Reconnecting will never run a job again.
• Cancellation. Cancelling a job will stop it and clean up the processes it started. Work elsewhere whose outcome cannot be known will be reported as unknown, not as undone.
• Built programs. Keep each executable and firmware image with its fingerprint and a record of what went into it.
• Devices. Flash and monitor boards through a connector that runs on the machine the boards are plugged into, with one operation per device at a time.
• Deployments. Stage deployments and roll them back, as Deployment and rollback describes.
• Keeping backups. Keep backups of everything above, and restore them.

Access

• Local by default. The server will listen only on its own machine until you configure otherwise, and the ael command will pair with it using a short-lived code.
• Remote only over HTTPS. Remote access will need HTTPS with a trusted certificate and explicit configuration.
• Checked every time. Every job, built program and device operation will be checked against who is asking, including when a job is resumed. Sessions will expire and will be revocable, and credentials will be redacted from logs and output.
• Only defined operations. The server will run the operations listed above, never arbitrary commands.

Keeping backups, restoring and retention

• Consistent backups. A backup will capture the server's records together with every file they refer to, each with its fingerprint, and will be marked complete only when all of it is written.
• Safe restore. A restore will go into a clean server and check every fingerprint first. A partial, damaged or incompatible backup will be refused, and a healthy installation will never be overwritten by one.
• Restarts. After a restart, queued and running jobs will be reconciled. Only work you marked as restartable will resume, and a model or tool call will never be made again just because the server stopped.
• Retention. Retention rules will remove old jobs, logs and builds, but never anything that an active release, a possible rollback or a backup still needs.

Operating the server

• Health. The server will report readiness and the health of its storage, job queue, workers and device connectors. A model provider being unavailable will be reported separately and will not make the server unhealthy.
• Shutdown and restart. It will drain work within a deadline when it stops, and its logs will rotate like any other AEL program's.
• Upgrades. An upgrade of the server will be able to roll back to the previous version.
• Hardware. Hardware requirements will be published with measured results. They will not include running models, which will be the work of the model service you choose.

What it will not be

• Not needed to run programs. Programs built through the server will start and run without it.
• Not for untrusted code. It will be designed for your own projects, not for running untrusted programs from the public.

Related

• Deployment and rollback: plans, staging and rollback.
• Microcontroller boards: flashing and monitoring devices.
• Logging and monitoring: health signals and logs.