Stacktide is under active development. The core systems are in place. We are building out the rest of the platform and working with early design partners.

The initial launch will focus on deploying Docker containers directly to VMs and bare-metal servers, not orchestrators like Kubernetes. We want to make the core workflows solid before adding orchestrator complexity.

Stacktide provides a fully managed developer platform, works with your existing infrastructure, and doesn’t need access to your cloud account to work.

CI/CD lets you automate anything you want, but you need to glue everything together yourself.

Platform as a Service (PaaS) providers like Heroku give you the developer platform, but it only works with their infrastructure. Self-hosted PaaS solutions solve that, but then you have to either run the platform yourself or give a third-party broad access.

Stacktide is closest to an Internal Developer Platform (IDP). Like an IDP, it integrates with your existing infrastructure and enables self-service workflows on top of your existing tools. However, Stacktide is opinionated like PaaS, does not require any external tools to work except Docker, and does not allow developers to create or delete cloud resources.

The zero trust architecture is very rare for a developer platform, and closest to the way Tailscale works when Tailnet Lock is enabled.

Any amd64 or arm64 Linux server with Docker installed will work. The official packages will install a compatible version of Docker if necessary.

You need enough capacity for your workloads. We don’t have official requirements for the agent yet, but the overhead is negligible.

You don’t need to open any ports, but you do need to allow outbound TLS connections to the control plane.

We do not provision infrastructure. You install the agent on your own servers, typically with cloud-init or by SSHing in. The agent is easy to install with Infrastructure as Code tools like Terraform.

When a new project is deployed, it claims some capacity from the infrastructure you already connected.

The control plane is designed to be highly available and will run across multiple availability zones.

If the control plane is unavailable, running workloads are not disrupted.

Deployments are not possible through Stacktide if the control plane is unreachable. The agent will reconnect as soon as possible and re-sync.

Stacktide does not replace orchestrators like Kubernetes; it works with your orchestrator or underlying container runtime.

This is by design: changes are coordinated across your infrastructure by a global control plane, but real-time scheduling decisions are always made within your network.

Teams often adopt a container orchestrator prematurely in order to deploy across multiple hosts. Stacktide can deploy across multiple hosts by pushing workloads directly to the Docker daemon.

Without an orchestrator, containers will not automatically migrate across hosts if a host fails. You cannot treat your servers as one big pool of compute; placement must be defined at deploy time. Service discovery and load balancing must use external infrastructure.

Deploying directly to Docker works best for stateless shared-nothing web apps with a few background services. Your typical Rails, Laravel, or Django app will work great. You can avoid the complexity of clustering when you don’t need it.

Microservices, highly variable workloads like ML pipelines, and stateful clustered systems like Kafka do not work well without an orchestrator. Although we intend to support Kubernetes, Stacktide will never be a good fit for many of these workloads because the workflow is so different.

The security model is still being formalized. Details are subject to change as we work with early design partners.

The agent that runs on your servers is open source. The agent API follows the principle of least privilege and does not allow carte blanche access to your servers or the Docker socket. All operations are authorized locally by the agent.

Communication with the control plane uses an outbound TLS connection. The agent authenticates with a public key. The private key never leaves the server.

The contents of your git repository, such as your Dockerfile or docker-compose.yaml, determine what runs on your servers. The agent pulls directly from your git provider.

Stacktide does not have access to your source code by default. The Github app requires read access. You can still deploy from Github without granting read access using your own deploy keys.

Container images are distributed peer-to-peer directly between agents or via your own container registry. Peer-to-peer image pulls are mutually authenticated using the agents’ public keys.

The control plane stores deployment state, logs, metrics, and metadata. It does not store source code, build artifacts, or service volumes. All data is encrypted at rest.

Sensitive environment variables and secrets are end-to-end encrypted. They can only be decrypted by your agents.

Developers authenticate using your existing identity provider, such as Github. Access to the web console and API is authorized by Stacktide using your configured ACL policy.

Sensitive actions such as SSH access or updating secrets must use the CLI. CLI access is authenticated using a per-device public key. The private key is stored in the OS keychain and never leaves the device.

The control plane is not trusted to distribute agent and device keys. All updates to the set of trusted keys must be signed by an existing agent or device. We are fairly confident we can do this with lower friction than the status quo.

Stacktide does not replace CI, Infrastructure as Code, or workflow engines: it cannot be used to run tests, provision infrastructure, or run batch jobs.

Stacktide does not replace orchestration. The control plane will not re-schedule workloads across hosts, auto-scale, or make dynamic placement decisions. If you need orchestration, you cannot use Stacktide until Kubernetes support is available.

The platform is opinionated about developer workflows like a PaaS. We offer hooks and plugins, but you can’t customize everything.

Every project needs to be connected to a git repository. For security and reproducibility reasons, many changes can only be made through Git and cannot be made through the web console.

There is limited support for stateful workloads. It will be possible to mount volumes, but there is no built-in support for running databases. You can run SQLite but you shouldn’t run Postgres. Use a managed database or provision it outside of Stacktide.