Integrations
Connect the external services behind application delivery
Manage Git, CI, registries, storage, email, private access, variables, and custom service connections without recreating credentials in every environment.
- Keep credentials and service configuration out of application code
- Reuse integrations across multiple environments and projects
- Connect source, delivery, storage, configuration, and access services
Centralize service connections instead of scattering them through code
External services are easier to manage when configuration lives in a platform workflow rather than in repositories and one-off environment files.
When integrations are modeled at the platform layer, teams can attach the same provider access to multiple stacks and environments without recreating configuration in every repository.
- Keep credentials out of source control and repeated manual setup.
- Reuse integration definitions across multiple apps and environments.
- Apply stronger operational ownership to shared external services.
Source and delivery
Connect Git providers, CI systems, and container registries to build and deployment workflows.
Data and storage
Attach backup storage and managed data services without moving their credentials into application code.
Configuration and email
Provide runtime variables, secrets, monitoring settings, and SMTP relay configuration to the services that need them.
Private access
Connect Cloudflare or Tailscale when an application or selected endpoints should not use ordinary public delivery.
Protect application endpoints through Cloudflare or Tailscale
Application Access integrations connect an app-level access policy to the provider your organization already uses.
Cloudflare supports identity-protected publishing and private-network delivery through Cloudflare One. Tailscale provides private HTTPS addresses inside a tailnet. Both can protect the complete app or only selected HTTP endpoints without requiring a provider-specific stack.
Cloudflare Application Access
Publish behind a Cloudflare Access policy or route enrolled devices to private app endpoints through Cloudflare One.
Tailscale Application Access
Make app endpoints reachable to authorized tailnet users and devices through stable private addresses.
Use variable providers to connect application configuration cleanly
Variable providers make external configuration easier to attach and reuse.
Wodby supports variable-style integrations that help teams inject the values applications need without embedding them directly into the codebase. That gives teams a more controlled place to manage runtime configuration and service credentials.
Teams can also create custom variable providers by entering a provider name, defining the fields that integration should collect, and choosing which environment variables Wodby will add to the connected app service container.
Reuse one provider across apps
Attach the same secret source to multiple stacks and environments instead of duplicating keys and tokens per project.
Map fields to runtime variables
Choose exactly which environment variables should appear in connected containers when the integration is attached.
Keep vendor credentials out of repos
Store API keys, DSNs, tokens, and provider settings in the integration model rather than inside application code.
Support custom provider schemas
Define your own provider name, fields, and variable mappings when the built-in catalog is not enough.
Relay email through SMTP providers your team already trusts
Email delivery is a common external dependency, and it should be easy to wire into application delivery.
SMTP integrations let services such as OpenSMTPD relay through the external email providers your organization already uses. That helps teams keep transactional email workflows aligned with the rest of the platform instead of treating them as an afterthought.
- Keep mail relay settings outside the application repository.
- Reuse trusted outbound email providers across multiple apps and environments.
- Treat transactional email as part of the same delivery model as builds, stacks, and runtime services.
Extend the model with custom providers when the catalog is not enough
Not every team relies on the same vendor set, so the platform should not force one narrow integration catalog.
If the exact provider you need is not already listed, Wodby also supports custom integration providers. That keeps the overall integration model flexible while preserving the benefits of centralized configuration and reuse.
For custom variable providers, you define the provider name, enter the field names the integration should expose, and map each one to the environment variable names that should appear inside connected app service containers.
Next step
Manage third-party dependencies without scattering secrets everywhere
Bring external services into the same operational model as your apps so configuration stays cleaner, safer, and easier to reuse.