Engineering
One Manifest from Local to Live
A small adios.yaml keeps build and runtime decisions close to the code, whether the source starts in a local folder or a shared workspace.
Deploy configuration is easiest to reason about when it lives beside the code it describes.
Keep the contract small
An Adios manifest names the runtime contract for a workload: how to build it, how to start it, which port it listens on, and which environment values or volumes it expects. Those are the details that usually drift when they live only in a dashboard or a hand-maintained runbook.
Putting them in adios.yaml makes the deployment path visible in code review. A teammate can see that a Node.js app builds with npm run build, or that a Go service compiles to a single binary, without first opening the platform console.
- —Build command is reproducible from a clean checkout.
- —Start command launches the production process, not a development server.
- —Port and bind address work inside an isolated runtime.
- —Required credentials use secret references rather than literal values.
name: api
runtime: node@23
type: api
build_cmd: npm install && npm run build
start_cmd: node dist/main.js
port: 8080Use the same file in every source flow
The source may begin as a local directory, a Git repository, or an Adios workspace. The manifest still gives the build and runtime layers the same instructions. That continuity matters when a quick prototype becomes a service the team needs to maintain.
You can change the framework code and the deploy contract together, run the checks that matter to the project, and promote the result without translating it into a second configuration system.
Explicit beats clever
A manifest should be unsurprising. Prefer a command a developer can run and debug over a chain of hidden conventions. Keep secrets behind secret references, declare persistent data explicitly, and make the health check reflect what the workload can actually serve.
That leaves less to remember when something fails and makes the path from source to production easier to inspect.
Review manifest changes as operational changes
Changing start_cmd, a health check, or a persistent volume can alter availability even when application code is untouched. Review those lines with the same care as a database migration: what happens to existing replicas, what data survives, and how will the new process prove readiness?
A useful pull request explains the old and new runtime behavior, includes the command used to verify the build, and names the rollback. The manifest is short, but it is still production code.