Adios
Automation · plans from $10/month

Deploy Adios workflows.Keep every step and failure inspectable.

Deploy scheduled jobs, webhook processors, approval gates, maintenance tasks, and operational automation from a versioned workflow manifest.

Keep the repositoryInspect build and logsCustom domains and TLS
Adios deploy

Candidate release

Adios workflows

Healthy

SOURCE

Git

REGION

de

ROUTE

HTTPS

01Source received

02Build completed

03Runtime started

04Health check passed

Promoted route

production.adios.run

A production path for

CronWebhooksEventsApprovalsHTTPPythonSQL

The production path

A working Adios workflows project still needs a safe release.

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.

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.

See which step failed and what it produced

Each run records step status, inputs, outputs, errors, waits, and approvals so an operator can inspect the work after the original trigger returns.

Use the right trigger for the job

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

Three steps keep the deployment path reviewable.

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.

  1. 01

    Start with source or a template

    Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.

    $adios login
  2. 02

    Review the deployment contract

    Keep commands, runtime or service version, health behavior, and secret references in adios.yaml.

    $git diff -- adios.yaml
  3. 03

    Deploy and inspect the result

    Follow build and runtime evidence, verify the candidate, and open the promoted route or service connection.

    $adios up
adios.yaml
Your project
workflow_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/maintenance
Choose triggers, step kinds, dependencies, timeouts, and approval points based on the operational risk of the workflow.

Deployable starting points

Start Adios workflows from a template when the repository is not ready.

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

Node.js Express

Express, Fastify, Hono, and NestJS starters with production-ready start commands.

JavaScriptnpm
Template key
node-express
Runtime
node
Repository
templates
Source path
nodejs/express
git clone https://github.com/adiosdotdev/templates.git
cd templates/nodejs/express
adios up

API starters

Python FastAPI

FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.

Pythonpip
Template key
python-fastapi
Runtime
python
Repository
template-python-fastapi
Source path
.
git clone https://github.com/adiosdotdev/template-python-fastapi.git
cd template-python-fastapi
adios up

API starters

Go Chi

Gin, Chi, Echo, Fiber, and Beego starters with compiled production binaries.

GoGo modules
Template key
go-chi
Runtime
go
Repository
templates
Source path
go/chi
git clone https://github.com/adiosdotdev/templates.git
cd templates/go/chi
adios up

Before production

Verify the workload.Then promote it.

The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.

Ready when…

  • Every trigger has an owner and expected input.
  • Secrets use references rather than literal values.
  • Retries and duplicate execution are safe.
  • Approvals protect irreversible or high-impact steps.

Preview when…

  • A step writes, deletes, bills, or notifies externally.
  • The workflow can run twice for the same event.
  • Long waits or downstream outages change timeout behavior.

Questions, answered

What to know before deploying Adios workflows.

Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.

What can trigger an Adios workflow?

A workflow can start from webhook requests, internal events, cron or scheduled triggers, and manual actions in the UI or CLI.

Which step types can a workflow run?

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.

How are workflow secrets handled?

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.

Can I inspect old workflow runs?

Yes. Run history records step state, outputs, and errors so operators can trace what happened after the original trigger or request has finished.

Can workflows coordinate an application API?

Yes. HTTP steps can call your application routes, while data, wait, approval, and command steps coordinate the surrounding automation.

The first release

Deploy Adios workflows with the source and evidence attached.

Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.