Product
More ways to start on Adios
The template catalog now reaches beyond a handful of app starters. It covers web apps, APIs, databases, caches, and queues in one place.
A useful template should remove setup work without hiding the decisions you will need to own later. That is the standard behind the expanded Adios catalog.
Start with the shape of the workload
The catalog is now organized around three practical starting points: web apps, API starters, and data services. You can begin with Next.js or a static Nginx site, choose an API framework in Node.js, Python, Ruby, PHP, Go, or .NET, or attach a service such as PostgreSQL, Redis, MongoDB, MySQL, or RabbitMQ.
Each entry exposes its variants instead of collapsing them into a generic framework label. Package manager, language, repository path, and deploy key stay visible before you launch anything.
The manifest is part of the template
Every complete template includes an adios.yaml file. It records the runtime, build command, start command, port, and any persistent volumes the workload needs. That makes the deploy configuration reviewable alongside the application code.
The result is a starter you can inspect locally, change in a normal Git workflow, and deploy with the same configuration you reviewed.
- —Inspect package.json and the production start command.
- —Confirm the service binds to the configured PORT on 0.0.0.0.
- —Call the health route before adding application code.
- —Commit the first domain change separately from template setup.
git clone https://github.com/adiosdotdev/templates.git
cd templates/nodejs/fastify
adios upTemplates are a starting line
The catalog is deliberately made of small, understandable projects. It does not try to predict your domain model or fill a repository with features you will delete. It gives the framework a production command, a health path where appropriate, and enough structure to begin real work.
Pick the closest runtime, deploy it, and then make it yours. The useful part is not avoiding configuration forever. It is starting from configuration that already runs.
Add state deliberately
When the webhook receiver needs deduplication, add PostgreSQL for durable event IDs or Redis for a short-lived idempotency window based on the required guarantee. The template catalog exposes both, but the framework starter does not silently choose one for you.
For example, a payment webhook that must never be applied twice belongs in a durable table with a unique provider event ID. A cache can reduce repeated work, but it should not become the only record of a financial event.