Catalog update
New stacks and boilerplates: Rails, Django, FastAPI, Flask, and more
Thirteen new stacks expand Wodby from application frameworks to runtimes and infrastructure. New boilerplates make Rails, Django, FastAPI, and Flask especially quick to launch, while Ruby, Python, Go, Prometheus, RabbitMQ, and more broaden what you can run.
Every application on Wodby starts from a stack: a reusable definition of services, links, integrations, configuration, and build settings that app instances inherit. Until recently, the catalog was strongest for PHP-based projects and generic runtimes. Teams building on Rails or on a Python web framework had to assemble that setup themselves from the ruby and python runtime services.
That is no longer necessary. Wodby now publishes ready-to-use boilerplates for Ruby on Rails, Django, FastAPI, and Flask, matched to framework stacks with databases and the supporting services real deployments need. These four are the featured application-framework additions, but they are only part of the update: the same catalog expansion adds runtime stacks, standalone infrastructure stacks, database administration tools, and services you can drop into stacks of your own.
Boilerplates for Rails, Django, FastAPI, and Flask
Each boilerplate is paired with a framework stack that builds the application image from Git. Wodby can import the boilerplate into a new GitHub or GitLab repository during app creation, giving you working application code and a stack-aware deployment path from the start. If you already have a project, connect its repository to the same stack instead.
The four featured here join Wodby's broader public boilerplate collection, which also covers Drupal, Express.js, Go, Laravel, Next.js, and other common starting points.
For examples using third-party CI systems, see the public wodby/wodby-ci repository. It includes pipelines for GitHub Actions, GitLab CI, and CircleCI.
Database-backed web apps, JSON APIs, and background jobs on the Ruby runtime.
- Ruby (Rails), PostgreSQL, and Valkey are enabled out of the box, with DATABASE_URL and REDIS_URL wired through stack service links.
- A Sidekiq service runs the same application image with the Sidekiq command, so workers and web share one build.
- Post-deploy actions prepare the database on every deployment and seed it once on the first one.
- RAILS_ENV follows the environment type, SECRET_KEY_BASE is generated as a secret, and a host authorization initializer is shipped as an editable config.
Boilerplate: wodby/rails-boilerplate
Full-featured Python web apps and APIs with an asynchronous task queue.
- Python (Django), PostgreSQL, and Valkey are enabled out of the box, with the database URL and the Celery broker URL provided as secrets.
- A Celery service is part of the stack and runs the same image as the web service.
- Post-deploy actions run migrations and collect static files.
- DJANGO_SECRET_KEY is generated per app, and DJANGO_DEBUG is only set for development environments.
Boilerplate: wodby/django-boilerplate
Async Python APIs and services served through ASGI workers.
- Python (FastAPI) is the primary service, served by Gunicorn with the Uvicorn worker class.
- PostgreSQL and Valkey ship with the stack and are switched off by default; enable either one when the API needs it.
- Database, cache, and mail links are already mapped, so enabling a service is a switch rather than a reconfiguration.
Boilerplate: wodby/fastapi-boilerplate
Lightweight Python web apps, internal tools, and small custom services.
- Python (Flask) is the primary service, served by Gunicorn.
- PostgreSQL and Valkey ship with the stack and are switched off by default.
- FLASK_DEBUG is only set for development environments.
Boilerplate: wodby/flask-boilerplate
All four stacks also carry the same optional extras: Mailpit for catching outbound mail in development, OpenSMTPD for real delivery, Gotenberg for PDF and document rendering, and a Cloud PostgreSQL connection service for teams that prefer a managed database over one running inside the stack. They are part of the stack definition and switched off until you need them.
Background workers come with the stack
Rails and Django applications rarely stop at a web process. Both stacks include a worker as a derivative service: Sidekiq for Rails, Celery for Django. A derivative reuses the parent service's image, environment, and version, and overrides the command it runs.
In practice this means one build produces both the web service and the worker, they stay on the same code, and they still deploy and scale as separate services. The broker is already part of the stack, so there is no separate queue setup step.
Ruby, Python, and Go join the runtime stacks
Not every project fits a framework stack. The new Ruby, Python, and Go stacks cover custom web apps, APIs, workers, and services that bring their own framework or none at all.
A general-purpose Ruby stack for web apps, APIs, workers, and services outside Rails.
A flexible Python stack for applications and services that bring their own framework or run without one.
A general-purpose Go stack for compiled web applications, APIs, workers, and backend services.
All three follow the same shape as the framework stacks: the runtime is the primary service, and PostgreSQL, Valkey, mail, and document rendering are pre-linked and disabled until you turn them on.
New standalone service stacks
Some things are not applications you build, but infrastructure you want to run next to them. These stacks deploy as their own apps and can be reached by other apps in the same cluster.
Collect, query, and retain metrics with persistent storage and an editable Prometheus configuration.
AMQP message broker with the management interface, a metrics endpoint, and generated credentials.
Distributed in-memory cache with settings for cache memory, worker threads, and maximum connections.
Self-hosted OCI registry on CNCF Distribution, with filesystem or object storage and an optional Valkey metadata cache.
Accept tunnels from FRP clients and expose services that live behind private networks.
Self-hosted invitation page for public Slack communities, with optional Cloudflare Turnstile protection.
phpMyAdmin, pgAdmin, and Adminer
Database administration is now part of the service catalog rather than something you tunnel to from a laptop. Three web-based administration services can be added to any stack that already has a matching database service:
Link it to a MariaDB or MySQL service in the same stack.
Link it to a PostgreSQL service; the connection is pre-registered and configuration can persist on a volume.
A lightweight alternative that works with MariaDB, MySQL, and PostgreSQL.
Each one is linked to a database service inside the stack, so connection details come from the link instead of from hand-managed environment variables. Because they are ordinary stack services, they inherit the routing and access controls of the app they belong to, including Application Access when you want an administration endpoint reachable only through Cloudflare or a private tailnet.
More services for your own stacks
Everything above is also available as an individual service, so you can add Prometheus, RabbitMQ, Memcached, the Distribution registry, or the FRP server to a stack you maintain yourself instead of deploying it as a separate app.
The catalog also gained an Nginx Proxy service that forwards HTTP traffic to a linked backend with editable main and virtual host configuration.
Available now
All of these stacks and services are public. Browse the full stack catalog and service catalog to see what each one contains, then open Stacks in the Wodby dashboard and use Add stack to copy the one you want into your organization or project.
The copied stack is yours: add services, change configuration, publish revisions, and create apps from any published revision. It keeps a link to its origin, so you can sync catalog changes later or leave it exactly as it is. The stacks documentation covers how stack revisions, service links, and updates work.