Self-hosting your application
You host the application you build with AEL, the Agent Engineering Language, on servers you operate, with health checks for the storage, databases and models it declares, graceful shutdown and log rotation.
Your application runs on the server like any other program. Programs compile straight to self-contained native executables, with no interpreter or virtual machine to run and no second language to install unless you write functions in one.
What you run
You build the application for the target of your server, such as a console agent or an HTTP service:
ael build --target linux-x86_64 -o build/support --release
| What | Where it comes from |
|---|---|
| Your application | The native executable ael build writes. Programs build into standalone native binaries, including static Linux binaries. |
| Configuration and secrets | Files or environment variables on the server, read when the application runs, never written into the executable. A secret's value never appears in your source or in routine logs. |
| System prompts and files | Files you place on the server, the environment or configuration, each checked before the application reports ready. |
| What its agents declare | An agent, subagent or node declares the memory, skills, knowledge, storage and database it uses, each bound to a package you select, and the check refuses any use it did not declare. |
| Its models | The model service each model binding names. |
AEL itself contains no database: the memory, knowledge and durable state of your runs live in the storage, database and vector-store packages you select. On your servers, you provide what each of them keeps its data in: a directory, object storage or an SQL database you run.
Health checks
Your application reports its own health, with health checks for the storage, databases and models it declares:
- What it declares. Each storage point, database binding and model binding its agents declare has a health check.
- No secrets. A health report never shows a credential or the value of a secret.
- No tokens for health. The check of a model binding says whether its model service can be reached, and never calls a model.
- Ready means ready locally. The application reports that it is ready once its own configuration, prompts and files are validated and it can accept a request. Whether a model service or a store can be reached is reported separately, because the application may be ready while one of them is offline.
- Fail promptly. A missing required setting, credential, system prompt or file stops the application promptly with a clear error, never with a false report that it is ready.
Durable runs
A run is durable only when its agent declares a storage point, a storage package you select that keeps the run's state in a directory, in object storage or in an SQL database you run; without one, the run runs to completion and keeps nothing.
- After a restart. A run whose agent declares a storage point resumes from it when your application starts again. A run without one does not.
- The storage point's health. The storage point is among what the application declares, so its health check covers it.
Bindings and storage describes the storage point.
Graceful shutdown and drain
- Drain. On a stop signal your application stops taking new work, then finishes or cancels the work it has within a bounded deadline, and exits. A one-shot program keeps its exit status.
- Unknown stays unknown. Work cancelled at the deadline whose outcome outside your program is not known is reported as unknown, never as undone, and is never replayed.
- Child agents too. Cancelling a run also cancels its child agents.
Logs and log rotation
Structured logs go to the console, a file, or custom or remote sinks, with redaction, rotation and retention.
- Rotation. File logs rotate, and old files are removed under the retention you set.
- Redacted by default. Logs record what happened, not your data, and credentials are never logged.
Logging and monitoring describes where logs go and what each event carries.
Staged deployments and rollback
Deployments are staged, and you can roll each one back. A new version reaches your servers only through a plan you have reviewed:
ael deploy plan
ael deploy apply --plan <plan>
The plan puts the new executable in place beside the running one, checks that it reports ready, then switches it on. Runs already under way keep the version they started with until they end, and rolling back returns to the previous compatible version. Deployment and rollback describes plans in full.
Honest limits
- You operate the servers. Self-hosting runs your application on machines you run: the servers, and the stores behind what your agents declare, are yours to operate.
- Durability needs a storage point. A run whose agent declares none runs to completion and keeps nothing.
- Rolling back does not undo effects. Rolling back does not undo an effect that already happened outside your program, such as a message that was sent or a payment that was made.
- Models are the model service's. A model's availability and response times belong to the model service its binding names, not to your application.
Related
- Desktop and server: the executable your servers run, and its resource limits.
- Containers: the same application in a minimal container image.
- Deployment and rollback: plans, staging and rollback.
- Logging and monitoring: health signals and logs.
- Bindings and storage: what an agent declares, and the storage point.