App service controls
Control each app service without dropping into raw platform plumbing
Manage runtime configuration, resources, replicas, Helm values, links, volumes, tokens, actions, metrics, and terminal access from the app service workflow.
Every app instance is made of services, and each service needs a practical control surface. Wodby keeps operational settings close to the service they affect so teams can tune runtime behavior, inspect workloads, manage secrets, and connect dependencies without scattering changes across Kubernetes manifests, CI scripts, and ad hoc tools.
Treat the app service as the operational unit
Wodby apps are built from services, and each service exposes the controls needed to run that part of the application.
App services connect the reusable stack definition to a specific app instance. That is where teams configure the runtime, review status, inspect metrics, connect dependencies, run service actions, and tune service-specific behavior.
Overview
See status, service details, workload access, and the operational entry points for the running service.
Configure
Adjust environment variables, resources, Helm values, settings, volumes, links, and other service controls.
Operate
Use actions, database workflows, metrics, logs, and terminal access to handle day-to-day service work.
Manage configuration without hiding important side effects
Some configuration changes affect a running service, while others require a rebuild. The platform should make that distinction visible.
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.
Tune the runtime shape of each service
Service-level controls should cover both platform resources and application-specific settings.
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.
Connect service dependencies explicitly
Runtime services rarely stand alone. They need databases, storage, routes, integrations, and other services.
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.
Links
Connect services through the relationship model defined by the stack.
Volumes
Attach persistent or shared storage where the service template supports it.
Databases
Run database-aware workflows from the service surface when the app service manages a database.
Run service operations from the same place teams inspect service state
Operational commands are easier to use when they are attached to the service they affect.
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.
For scheduled service work, pair app service actions with scheduled cron tasks.
Open a web terminal when direct workload inspection is needed
Some troubleshooting requires an interactive shell, but that should not require exposing a public SSH port.
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.
- Open a shell from the app service overview when the service is healthy enough for interactive access.
- Target the workload and container that need inspection.
- Use direct runtime inspection without publishing a public SSH endpoint.
Use service controls with the rest of the platform
Service-level control is strongest when it stays connected to environments, deployments, routes, and observability.
App service controls fit between the reusable stack and the running app instance. Use them with CI/CD, endpoints and routing, and observability to keep service changes visible from release through runtime.
Next step
Keep service operations where the team already manages the app
Give teams a practical control plane for the service-level changes they make every day, while keeping those changes tied to the stack and app instance model.