Connection stack for apps that use managed PostgreSQL services such as Amazon RDS instead of self-hosting Postgres inside the stack.
Why teams use this stack
Start new instances with the right services already linked
Use a ready service baseline.
Choose managed database providers for each environment
Keep connection stacks ready for supported DB providers.
Keep services current with managed stack auto-updates
Included services get managed updates through new revisions.
Reuse one stack across all environments
Create dev, staging, and preview copies with per-environment configuration.
Services
These are the services enabled by default when you create a new instance from the Cloud PostgreSQL stack.
Stack services can be configured, added or removed for specific instances, and their versions can be changed as your workload evolves.
| Stack service | Base service | Role |
|---|---|---|
| Cloud PostgreSQL | 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.
Integrations
This stack is built to connect your apps to supported managed database providers. Keep provider-specific connection details at stack level and reuse the same model across environments.
Pick the managed database provider that fits each environment without rebuilding how the app connects.
Supported managed database providers
Explore all integrations for this stack to browse managed database providers supported by this stack.
Get started
Launch this database stack with its service defaults, data workflows, hosting options, and managed updates already in place.
Stack control
Included service updates can mark the stack as outdated. Upgrading the stack releases a new revision, but existing instances stay on their current revision until you decide to move them or enable automatic updates.
Explore stack control to see how revisions, app-by-app upgrades, and auto-updates work.
Environments
Reuse the same Cloud PostgreSQL stack for development, staging, production, customer-specific environments, or short-lived feature branches, with per-environment values and configuration overrides where needed instead of rebuilding the stack every time.
Create development and staging environments from the same stack
Teams can test against the same enabled services and integrations instead of maintaining a separate setup for non-production environments.
Spin up dedicated feature environments when teams need them
Short-lived environments can reuse the same stack instead of forcing teams to create a new stack for every branch or task.
Preview app instances on branch push are coming soon
Automatically create a new preview environment on branch push. Coming soon.
Explore app instances for reusable environments, preview apps, and branch-based workflows.
Get started
Reuse the same database stack for development, testing, and production environments without rebuilding the service definition each time.
FAQ
Connection stack for apps that use managed PostgreSQL services such as Amazon RDS instead of self-hosting Postgres inside the stack. Instances created from this stack inherit the services enabled by default, attached integrations, hosting options, and stack revision history.
Instances inherit the services enabled by default, third-party integrations, deployment model, and stack revision history. Environment-specific values can still differ per environment.
Yes. The same stack can be used for development, staging, production, and other related environments so you do not rebuild the stack for every environment.
When an included service gets an update, the stack can be marked as outdated. Upgrading releases a new stack revision, but existing instances stay on their current revision until you upgrade selected ones manually or enable automatic updates.
They belong in the stack so SMTP relays, backup storage, managed databases, and other providers stay attached to the same reusable app definition.