Services

Start with the right services already in place

These are the services enabled by default when you create a new instance from the Tailscale stack.

Stack services can be configured, added or removed for specific instances, and their versions can be changed as your workload evolves.

Stack serviceBase serviceRole
TailscaleRequired

Explore the full stack service catalog for configs, settings, actions, cron, volumes, links, backups, and imports attached to each service in this stack.

Deploy

Choose how much infrastructure you want to manage

The application stack stays the same whether you choose Wodby’s managed cloud, infrastructure in your cloud account, or a server you operate yourself.

Wodby Cloud

Start without running a cluster in your own account when you want the most managed option.

Your cloud account

Keep the underlying infrastructure in your own cloud account while Wodby deploys and operates the application stack.

Server or dedicated host

Run the same application stack on a VM, bare-metal server, or dedicated host when that model fits your workload.

Explore hosting options for this stack to compare managed cloud, customer-cloud, and server-based deployment models in more detail.

Integrations

Connect the stack to private networking integrations

Keep private networking integrations attached to the stack instead of reconnecting tailnets and related access per environment.

That makes it easier to bring new environments and related workloads into the same private network without rebuilding the connection model.

Supported private networking providers

Explore all integrations for this stack to browse private networking providers supported by this stack.

Git-managed configuration

Keep your stack configuration in Git

Store the application blueprint in a stack.yml template alongside your code. Version service definitions, defaults, settings, and environment behavior while Wodby turns approved source changes into controlled stack revisions.

Version the application blueprint

Review stack configuration through commits and pull requests before it reaches an environment.

Import updates as new revisions

Follow an approved branch or semantic-version tags without changing running app instances in place.

Keep service updates enabled

Control Git template updates and service auto-updates separately, so customized stacks can still receive eligible releases.

Explore Git-backed stacks and see how they work with automatic updates.

Security and maintenance

Stay secure with automatic service updates

Enable service auto-updates at stack level to pick up eligible security patches and maintenance releases. Wodby creates a new stack revision instead of changing running instances in place, so every update stays visible and reviewable.

Choose which app instances should auto-upgrade and limit production rollouts to a local-time maintenance window. Development and staging can move sooner while production follows your security and maintenance policy.

Explore automatic updates to see how policies, revisions, maintenance windows, and app instance auto-upgrades work.

Observability and debugging

Understand what running services are doing

Keep the signals and tools for day-to-day troubleshooting close to each app instance, from a quick health check to direct inspection inside a running container.

Stream live container logs

Follow app service output in real time and select a specific workload or container when a service exposes more than one.

Track runtime health

Inspect app instance and service metrics for CPU, memory, storage, readiness, and restarts before changing resources or scaling.

Debug with a web terminal

Open an interactive shell in a running service container for quick inspection and one-off commands without exposing a public SSH port.

Explore observability for logs and metrics, or review service configuration for web terminal access and other runtime operations.

Environments

Create development, staging, and production environments

Launch development, staging, production, or customer-specific environments from the same Tailscale stack, then tailor values and configuration to each one.

Start from a consistent baseline

Use the same enabled services and integrations across development, staging, and production.

Customize each environment

Override values, configs, and settings without changing the shared stack definition.

Explore environments for development, staging, and production workflows.

Get started

Create a new Tailscale environment

Reuse the same stack across environments without rebuilding the definition for every new instance.

FAQ

Common questions about the Tailscale stack

What does the Tailscale stack include?

Tailscale integration stack for private networking between apps, services, and operators. Instances created from this stack inherit the services enabled by default, attached integrations, hosting options, and stack revision history.

How can one stack support multiple apps and environments?

You can reuse the same stack for multiple similar apps and for development, staging, production, and other environment types. The stack defines the shared services and defaults, you can set different values for env types such as dev and prod, and each app instance can still be configured individually.

How do stack updates work?

When an included service gets an update, the stack can be marked as outdated or create a new revision automatically under its update policy. Existing instances stay on their current revision until you upgrade them manually or enable stack auto-upgrades with a maintenance window.

How do integrations work with this stack?

Use the Integrations section to attach reusable connections created from supported providers. That keeps credentials, variables, and external services connected to the stack instead of configuring them separately for every app instance.

Can app instances from this stack run on different infrastructure?

Yes. Development and production instances from the same stack can run on different hosting models, including Wodby Cloud, managed Kubernetes, and self-hosted Kubernetes on a VM or dedicated server, while keeping the same stack definition and upgrade path.