Vanilla Matomo
For Matomo
wodby/matomo-boilerplateApplication stack
Matomo (buildable) stack
Matomo (buildable) application stack for source builds, reusable runtime configuration, and versioned app upgrades on Wodby.
Start with this stackWhy teams use this stack
Ship faster with ready boilerplates and CI/CD
Build, run post-deployment scripts, and recover through one release workflow.
Keep stack configuration in Git
Version stack.yml and import approved changes as new revisions.
Stay secure with automatic stack maintenance
Control eligible updates and environment maintenance windows.
Monitor and debug running services
Stream logs, inspect metrics, and open a web terminal.
Route traffic through managed endpoints
Use technical routes, custom domains, HTTPS, and published ports.
Reuse one stack across environments
Create development, staging, and production with tailored configuration.
Services
Start with the right services, then make the stack your own
The Matomo (buildable) stack comes with these services already connected. The table shows which ones are enabled by default when you create an app environment and, where services depend on each other, how they are linked.
When you add the stack to your organization, the copy is yours to change. Changes go into a draft that you publish as a new stack revision, and app environments pick them up when they upgrade.
Add services
Add any service from the catalog, such as a cache, a search engine, or a mail relay, and link it to the services that use it.
Remove what you do not need
Leave optional services out when you create an app, disable a service in one app environment, or remove it from the stack for every environment.
Change how services connect
Point a link at another service in the stack or, where the link allows it, at a service of another app or at custom values such as a managed database. Change it for the whole stack or for one app environment.
| Stack service | Base service | Role | Links |
|---|---|---|---|
| Matomo (buildable) | Primary |
| |
| MariaDB | Enabled by default | — | |
| Ganesha NFS provisioner | Enabled by default | — | |
| OpenSMTPD | Enabled by default | — |
Explore the full stack service catalog for configs, settings, actions, cron, volumes, links, backups, and imports attached to each service in this stack. The stack configuration guide covers adding services, removing them, and changing links.
Deploy
Choose where it runs. Wodby maintains it either way.
The application stack stays the same on Wodby Cloud, in your own cloud account, or on your own server. Wodby keeps Kubernetes, the cluster infrastructure, and the stack up to date wherever it runs, so the choice comes down to where you want the resources and what you want to pay.
Wodby Cloud
Wodby hosts the cluster, so there is no cloud account or server to set up first.
Your cloud account
Keep the cluster and its resources in your own cloud account. Wodby creates it and keeps it up to date.
Server or dedicated host
Run the same stack on a VM, bare-metal server, or dedicated host at the lowest cost. You keep the server’s operating system updated.
Explore hosting options for this stack to compare managed cloud, customer-cloud, and server-based deployment models in more detail.
CI/CD
Start shipping from ready boilerplates and stack-aware CI/CD
Matomo can build from source as part of this stack.
Start from a compatible public boilerplate or connect your own repository from a supported Git provider. External CI and registry integrations still fit the same stack-aware build and release flow.
Release safety
Run post-deploy scripts
Run migrations, cache clears, and other jobs after a successful deployment.
Recover from rollout failures
Try to restore the last successful release when health checks fail.
Restore a previous build
Redeploy an eligible build from history without rebuilding it.
Build rollback restores application images, not stack configuration or persistent data.
Public boilerplates
Container registries
Explore CI/CD for this stack for boilerplates, Git connections, post-deployment scripts, deployment history, rollback controls, CI providers, and registries.
Routing and endpoints
Publish and control application endpoints
Services in this stack declare the endpoints and ports they can expose. Each app environment can start on default technical domains, then add custom domains, HTTPS, access controls, redirects, or published TCP and UDP ports as needed.
Default technical domains
Reach supported services on generated Wodby domains, then attach custom domains when ready.
Automatic Let's Encrypt HTTPS
Provision and automatically renew trusted certificates for supported public routes.
Authentication and route controls
Protect routes with HTTP basic auth, redirect alternate domains or paths, and tune HSTS, no-index, upload limits, and more.
Explore routing and endpoints to see technical routes, custom domains, managed certificates, route controls, redirects, and published ports.
Private app access
Deploy Matomo (buildable) behind private access
Choose private app access during app creation to keep every eligible HTTP endpoint behind an approved identity or private network. Protect the complete app, or only admin, staging, dashboard, and other restricted web surfaces.
Cloudflare
View integrationPublish behind a Cloudflare Access identity policy or keep endpoints inside a Cloudflare One private network.
Tailscale
View integrationGive authorized tailnet users and devices stable private HTTPS addresses for the app.
Explore private app access to compare identity-aware access through Cloudflare Access with private-network access through Cloudflare One or Tailscale.
Databases
Choose the right database model for each environment
This stack includes container-based databases such as MariaDB. You can also add managed database services when you want the database to run outside the stack.
Container databases in this stack
Managed database integrations
Explore database options for this stack for container services, managed providers, and the connection model used by this stack.
Backups
Automate backups and move data between environments
Container-based services in this stack can run automatic backups, upload archives to connected cloud storage, and import working data into other environments when teams need realistic copies.
Run automatic backups on a schedule
Keep backup workflows attached to the stack instead of rebuilding them manually for each environment.
Refresh development and staging
Import an archive, uploaded file, or URL to create realistic non-production data.
Upload backup archives to cloud storage
Send backup archives to third-party storage instead of keeping them only inside the platform.
Services with backup workflows
Backup storage integrations
Explore backups and migration workflows for archive destinations, restore paths, and ways to move working data onto Wodby.
Deliver email reliably with trusted SMTP providers
OpenSMTPD in this stack can relay outbound mail through trusted SMTP providers instead of relying on local delivery.
Email services in this stack
Trusted SMTP providers
Explore email delivery for this stack for development mail capture, SMTP relays, and provider-backed delivery.
Integrations
Connect and reuse integrations
Attach reusable integrations to the stack so every new app environment starts with the same external connections, variables, and credentials instead of copying values by hand.
That includes product integrations like Algolia, AWS, Anthropic, Auth0, and Brevo, and others.
OpenAI
View integrationBring API keys and model settings into your apps without scattering secrets.
Anthropic
View integrationStandardize AI credentials once and reuse them across environments.
Intercom
View integrationManage customer messaging credentials centrally and reuse them across environments.
Sentry
View integrationAttach monitoring variables cleanly to services without editing code.
Stripe
View integrationKeep payment-related secrets controlled and consistent per environment.
Mailchimp
View integrationKeep email marketing keys and audience settings consistent without scattering config.
Explore all integrations for this stack to browse email relays, storage, CI/CD, Git, managed databases, registries, and variable-based providers.
Configuration and customization
Customize services for each environment
Tune the config files and settings exposed by each service without changing its image or rebuilding the stack. Start from the stack defaults, then override only what a particular environment needs.
Explore configs and settings to see exactly what can be customized for each service in this stack.
Git-managed configuration
Keep your stack configuration in Git
Store the application blueprint in a stack.yml template alongside your code. Version service definitions, defaults, settings, and environment behavior while Wodby turns approved source changes into controlled stack revisions.
Version the application blueprint
Review stack configuration through commits and pull requests before it reaches an environment.
Import updates as new revisions
Follow an approved branch or semantic-version tags without changing running app environments in place.
Keep service updates enabled
Control Git template updates and service auto-updates separately, so customized stacks can still receive eligible releases.
Explore Git-backed stacks and see how they work with automatic updates.
Cron and actions
Keep recurring jobs and maintenance steps repeatable
Cron schedules and lifecycle actions are part of the stack, so maintenance workflows and recurring jobs can be reused across environments instead of recreated manually.
Explore cron schedules and actions to see the repeatable maintenance and scheduled jobs defined for this stack.
Security and maintenance
Stay secure with automatic service updates
Enable service auto-updates at stack level to pick up eligible security patches and maintenance releases. Wodby creates a new stack revision instead of changing running app environments in place, so every update stays visible and reviewable.
Choose which app environments should auto-upgrade and limit production rollouts to a local-time maintenance window. Development and staging can move sooner while production follows your security and maintenance policy.
Explore automatic updates to see how policies, revisions, maintenance windows, and app environment auto-upgrades work.
Observability and debugging
Understand what running services are doing
Keep the signals and tools for day-to-day troubleshooting close to each app environment, from a quick health check to direct inspection inside a running container.
Stream live container logs
Follow app service output in real time and select a specific workload or container when a service exposes more than one.
Track runtime health
Inspect app environment and service metrics for CPU, memory, storage, readiness, and restarts before changing resources or scaling.
Debug with a web terminal
Open an interactive shell in a running service container for quick inspection and one-off commands without exposing a public SSH port.
Explore observability for logs and metrics, or review service configuration for web terminal access and other runtime operations.
Environments
Create development, staging, and production environments
Launch development, staging, production, or customer-specific environments from the same Matomo (buildable) stack, then tailor values and configuration to each one.
Start from a consistent baseline
Use the same enabled services and integrations across development, staging, and production.
Customize each environment
Override values, configs, and settings without changing the shared stack definition.
Explore environments for development, staging, and production workflows.
Get started
Create a new Matomo (buildable) environment
Use the same stack for development, staging, production, and other app environments without rebuilding the definition for each environment.
FAQ
Common questions about the Matomo (buildable) stack
What does the Matomo (buildable) stack include?
Matomo (buildable) application stack for source builds, reusable runtime configuration, and versioned app upgrades on Wodby. App environments created from this stack inherit the services enabled by default, attached integrations, hosting options, and stack revision history.
How can one stack support multiple apps and environments?
You can reuse the same stack for multiple similar apps and for development, staging, production, and other environment types. The stack defines the shared services and defaults, you can set different values for env types such as dev and prod, and each app environment can still be configured individually.
How do stack updates work?
When an included service gets an update, the stack can be marked as outdated or create a new revision automatically under its update policy. Existing app environments stay on their current revision until you upgrade them manually or enable stack auto-upgrades with a maintenance window.
How do integrations work with this stack?
Use the Integrations section to attach reusable connections created from supported providers. That keeps SMTP relays, backup storage, managed databases, and other external services connected to the stack instead of configuring them separately for every app environment.
How should I handle CI/CD for buildable services in this stack?
Review the stack’s CI/CD options for compatible boilerplates, Git providers, and repository-based pipelines, including post-deployment scripts and rollback controls.
You can also use the public wodby/wodby-ci repository as a starting point or reference.
If you prefer your own CI system, run Wodby CLI from GitHub Actions, CircleCI, or similar. It reads your stack information and performs the build, push, and deploy steps for connected services.
Can app environments from this stack run on different infrastructure?
Yes. Development and production app environments from the same stack can run on different hosting models, including Wodby Cloud, managed Kubernetes, and self-hosted Kubernetes on a VM or dedicated server, while keeping the same stack definition and upgrade path.