Customize application services without scattering configuration

Environment variables can be scoped for runtime behavior or build-time image creation. Runtime changes mark the service for redeployment, while build-time changes mark it for rebuild so the next image is created with the right inputs.

Wodby also provides generated runtime variables and service tokens for values the platform manages. Tokens can generate secrets and still allow overrides when a team needs to supply a specific value.

• Separate runtime variables from build-time variables.
• Use generated Wodby variables for app, instance, service, and route context.
• Manage service tokens and generated secrets without hardcoding sensitive values in code.
• See when a configuration change implies redeploy or rebuild work.

Teams can adjust resources and replicas for the service, configure service settings, and update Helm values where a service exposes Helm configuration. That keeps routine runtime tuning in the dashboard workflow while preserving the underlying stack model.

• Set service resources.
• Adjust replicas where the service supports scaling.
• Edit service settings exposed by the stack service.
• Update Helm values for Helm-backed services.
• Add annotations for platform integrations and workload behavior.
• Keep changes tied to the app instance that owns the service.

Wodby exposes links, volumes, configs, integrations, and database controls where the service uses them. That gives teams a clearer picture of how a service is connected and which dependencies should move with it across environments.

Service actions can expose repeatable commands for app-specific operations. Those actions can be simple dashboard buttons, output commands, post-deploy hooks, one-time post-deploy steps, or post-upgrade steps depending on the service definition.

• Run supported service actions without asking every user to remember the command.
• Use post-deployment and post-upgrade actions as part of safer release operations.
• Review task logs for long-running service work and failed operations.
• Open a web shell into a selected workload and container when direct inspection is required.

For scheduled service work, pair app service actions with scheduled cron tasks.

The web terminal opens an interactive session into a running service workload from the dashboard. Teams can choose the workload and container when needed, inspect runtime state, and run targeted commands without setting up separate SSH access.

Use the web shell for diagnosis, then move durable changes back into CI/CD or service configuration so the next deployment remains reproducible.