Self-hosted PostgreSQL database stack with PostGIS extensions for applications that need geospatial data and spatial queries.
Start with this stackWhy teams use this stack
Start with the right services already linked
Use a ready, configurable service baseline.
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
These services are included with the PostGIS stack. The table shows which ones are enabled or disabled by default when you create a new app environment.
Stack services can be configured, added or removed for specific app environments, and their versions can be changed as your workload evolves.
| Stack service | Base service | Role |
|---|---|---|
| PostgreSQL (PostGIS) | 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.
Deploy
The application stack stays the same whether you choose Wodby’s managed cloud, infrastructure in your cloud account, or a server you operate yourself.
Start without running a cluster in your own account when you want the most managed option.
Keep the underlying infrastructure in your own cloud account while Wodby deploys and operates the application stack.
Run the same application stack on a VM, bare-metal server, or dedicated host when that model fits your workload.
Explore hosting options for this stack to compare managed cloud, customer-cloud, and server-based deployment models in more detail.
Routing and 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.
Backups
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.
Configuration and customization
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
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.
Security and maintenance
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
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.
Follow app service output in real time and select a specific workload or container when a service exposes more than one.
Inspect app environment and service metrics for CPU, memory, storage, readiness, and restarts before changing resources or scaling.
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
Launch development, staging, production, or customer-specific environments from the same PostGIS 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
Reuse the same database stack for development, testing, and production environments without rebuilding the service definition each time.
FAQ
Self-hosted PostgreSQL database stack with PostGIS extensions for applications that need geospatial data and spatial queries. App environments created from this stack inherit the services enabled by default, attached integrations, hosting options, and stack revision history.
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.
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.
External integrations stay attached to the stack definition so SMTP relays, backup storage, managed databases, and related services can be reused across app environments.
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.