Integrations
Centralized integrations for secrets, email, and external services
Connect the services your applications rely on without hardcoding credentials or recreating the same setup in every environment.
Wodby integrations give teams a cleaner way to attach external dependencies to application delivery. Instead of burying configuration in repositories or repeating setup across environments, you can manage external service connections in one place and reuse them where needed.
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.
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.