Replace hidden cron scripts with a versioned workflow
Keep triggers, context, secrets, dependencies, and step commands in a manifest the team can review beside application source.
Deploy scheduled jobs, webhook processors, approval gates, maintenance tasks, and operational automation from a versioned workflow manifest.
Candidate release
Adios workflows
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source received
02Build completed
03Runtime started
04Health check passed
Promoted route
production.adios.run
A production path for
The production path
The application or service is only one part of production. Build evidence, runtime state, health, secrets, logs, routes, and the promoted version should remain inspectable together.
Keep triggers, context, secrets, dependencies, and step commands in a manifest the team can review beside application source.
Each run records step status, inputs, outputs, errors, waits, and approvals so an operator can inspect the work after the original trigger returns.
Start from a webhook, internal event, cron schedule, or manual action, then connect HTTP, data, wait, command, approval, and notification steps deliberately.
From source to release
Use the source and production behavior the project already has. The manifest records what the platform should build or provision and how the result becomes ready.
Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.
$adios loginKeep commands, runtime or service version, health behavior, and secret references in adios.yaml.
$git diff -- adios.yamlFollow build and runtime evidence, verify the candidate, and open the promoted route or service connection.
$adios upworkflow_id: nightly-maintenance
title: Nightly maintenance
enabled: true
version: "1"
triggers:
- type: cron
cron: "0 2 * * *"
timezone: UTC
secrets:
API_KEY: secret://API_KEY
steps:
- step_id: run-maintenance
name: Run maintenance
kind: http
command:
method: POST
url: https://api.example.com/maintenanceDeployable starting points
These application starters are useful when a workflow calls or coordinates your own API. The workflow itself is deployed from its workflow manifest.
API starters
Express, Fastify, Hono, and NestJS starters with production-ready start commands.
git clone https://github.com/adiosdotdev/templates.git
cd templates/nodejs/express
adios upAPI starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/template-python-fastapi.git
cd template-python-fastapi
adios upAPI starters
Gin, Chi, Echo, Fiber, and Beego starters with compiled production binaries.
git clone https://github.com/adiosdotdev/templates.git
cd templates/go/chi
adios upBefore production
The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.
Questions, answered
Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.
A workflow can start from webhook requests, internal events, cron or scheduled triggers, and manual actions in the UI or CLI.
Common step kinds include HTTP, JSON data transforms, waits, bash or Python commands, SQL, email, S3, request parsing, and approvals. Availability can depend on the execution context.
Declare secret references such as secret://API_KEY in the manifest. The sensitive value stays in secret storage rather than being committed with the workflow source.
Yes. Run history records step state, outputs, and errors so operators can trace what happened after the original trigger or request has finished.
Yes. HTTP steps can call your application routes, while data, wait, approval, and command steps coordinate the surrounding automation.
Related deployment paths
Deploy a persistent Node.js web process or worker from its existing package scripts, with release health, logs, secrets, routing, and Git history attached.
Run a Python web app or worker with the dependency file, process command, health route, and secret-backed configuration kept beside the source.
Compile a Go service from the repository, start the production binary, verify its health endpoint, and promote the exact version you reviewed.
Start RabbitMQ with management access, protect broker credentials, connect publishers and consumers, and test acknowledgements, retries, and persistence.
The first release
Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.