External systems connected through one integration model

Integrations for delivery, data, and external services

Integrations connect stacks and platform workflows to external systems and built-in platform capabilities. Use them for Git repositories, CI pipelines, image registries, backup storage, managed databases, SMTP delivery, VPN access, and variables and secrets.

That keeps provider access centralized instead of scattering credentials, provider settings, email relays, and operational glue across application code, environment files, and ad hoc scripts.

What integrations help with

Source, build, and images

Connect Git providers, CI pipelines, and registries so source, builds, and images stay inside one delivery model.

Backups and managed data

Send automatic backups to external storage and connect cloud database services to managed database providers.

Email, secrets, and private access

Keep SMTP relays, provider credentials, API keys, and VPN access outside application code and managed through integrations.

Built-in platform integrations

Use Wodby CI, Wodby Registry, and Wodby Blob Storage together with third-party providers from the same catalog.

Benefits

Why teams centralize integrations

Integrations keep external providers inside the same operating model as stacks, services, apps, backups, and deployment workflows.

Centralize provider access

Keep Application Access, Git providers, CI systems, registries, storage, managed databases, SMTP, networking services, and secrets in one integration catalog.

Keep third-party credentials out of code

Variable integrations centralize API keys, tokens, DSNs, and provider-specific settings instead of scattering them across repositories and environment files.

Cover delivery and operations together

Integrations are used for protected app delivery, source retrieval, build pipelines, image storage, backup uploads, managed databases, outbound email, and private connectivity.

Mix built-in and third-party providers

Use Wodby CI, Wodby Registry, and Wodby Blob Storage together with AWS, GCP, Azure, DigitalOcean, GitHub, GitLab, Docker Hub, and other providers.

Integrations catalog

Browse integrations by category

Search for providers, integration types, or related terms, then open the provider page to review the supported kinds and setup details.

Search also works with related terms such as `private app`, `zero trust`, `tailnet`, `s3`, `rds`, `email`, `secrets`, and `custom ci`.

Application Access

Application Access

Application Access integrations protect an entire app or selected HTTP endpoints through Cloudflare protected publishing, Cloudflare One private networking, or Tailscale.

  • Cloudflare

    Application Access

    Use Cloudflare Application Access to protect an entire app or selected HTTP endpoints without leaving matching ordinary public routes exposed.

    View integration
  • Tailscale

    Application Access

    Use Tailscale Application Access to protect an entire app or selected HTTP endpoints without leaving matching ordinary public routes exposed.

    View integration

Storage & backups

Storage & backups

Storage integrations receive automatic backup archives from container-based services and send them to providers such as Wodby Blob Storage, Amazon S3, Google Cloud Storage, Azure Blob, and DigitalOcean Spaces.

Managed databases

Managed databases

Database integrations connect cloud database services such as Cloud PostgreSQL, Cloud MySQL, and Cloud MariaDB to managed offerings like Amazon RDS, Cloud SQL, Azure Databases, and DigitalOcean Databases.

Git providers

Git providers

Git integrations connect repositories from GitHub, GitLab, and BitBucket so builds can pull application source code.

Networking services

Networking services

Networking-service integrations are used when a network node such as Tailscale is itself part of the stack workload. This is separate from protecting app endpoints with Application Access.

SMTP & email

SMTP & email

SMTP integrations let services such as OpenSMTPD relay outbound email through providers like Amazon SES and Brevo.

Registries

Registries

Registry integrations store built images in Wodby Registry, Docker Hub, or other compatible registries.

CI

CI

CI integrations connect build pipelines such as Wodby CI, GitHub Actions, GitLab CI, CircleCI, and Custom CI for external pipelines Wodby does not control through provider APIs.

Variables & secrets

Variables & secrets

Variable integrations store third-party credentials such as OpenAI keys, Stripe secrets, Sentry DSNs, Slack tokens, and other provider settings outside application code. Teams can also create custom variable providers by entering a provider name, defining fields, and choosing which environment variables Wodby should add to connected app service containers.

Need a different integration?

Start from the providers already in the catalog, or contact Wodby if you need a provider or integration kind that is not listed yet.

FAQ

Common questions about Wodby integrations

What is an integration on Wodby?

An integration connects a Wodby app, stack, or workflow to an external system or provider, such as Application Access, Git, CI, storage, managed databases, SMTP, networking services, registries, or variables and secrets.

How do Application Access integrations work?

Application Access is configured for an app rather than attached to a stack service. Cloudflare or Tailscale can protect the entire app or selected HTTP endpoints while Wodby manages provider endpoints, matching public routes, reconciliation, and cleanup.

How are integrations different from services?

Services are the building blocks that run inside stacks. Integrations connect those stacks and workflows to external systems or built-in platform capabilities.

What are variable integrations used for?

Variable integrations store third-party credentials such as API keys, tokens, DSNs, and other secret-based settings outside application code, while still making them available to the workloads that need them. Wodby also supports custom variable providers where you define the provider name, field names, and the environment variables that should be added to connected app service containers.

Can I create a custom variable provider?

Yes. You can create a custom variable provider by entering the provider name, defining the fields the integration should collect, and choosing which environment variables Wodby will add to the connected app service container when that integration is attached.

How do storage integrations work?

Storage integrations are used by automatic backup workflows and other storage-backed features. They let services upload backup archives to providers such as Wodby Blob Storage, Amazon S3, Google Cloud Storage, Azure Blob, and DigitalOcean Spaces.

How do database integrations work?

Database integrations are used by cloud database services such as Cloud PostgreSQL, Cloud MySQL, and Cloud MariaDB. They keep the app connection to managed databases such as RDS, Cloud SQL, Azure Databases, and DigitalOcean Databases inside the same Wodby workflow.

Can a provider support more than one integration kind?

Yes. Some providers support multiple integration kinds. For example, a cloud provider can expose storage, managed database, and Kubernetes-related capabilities at the same time.

Does Wodby include built-in integrations?

Yes. Wodby includes built-in options such as Wodby CI, Wodby Registry, and Wodby Blob Storage alongside third-party providers.

Can I use a CI provider that Wodby does not support directly?

Yes. Use Custom CI when your external pipeline runs Wodby CLI but Wodby should not connect to that provider API. The pipeline creates builds from the app service ID, releases images, and calls deploy itself.

Can I use an SMTP relay that Wodby does not list?

Yes. Use Custom SMTP to configure any standards-compatible upstream relay, then attach the integration to OpenSMTPD. Applications send mail to OpenSMTPD internally while it handles secure delivery through the external SMTP server.