# ADR: FTL Deployment Targets
**Author**: @sdouglas
**Reviewers**: @aat @jvmakine

## Description (what)

It has been decided that for now FTL will only target Kubernetes and local development via `ftl dev`.

## Motivation (why, optional)

Kubernetes has become pervasive and at this point it seems unlikely that FTL would be deployed anywhere else for the foreseeable future.

Kubernetes provides a great deal of infrastructure that we would otherwise need to implement ourselves, including:

- Load balancing via Services
- mTLS via Istio
- Runner lifecycle management through Deployments

Kube is also well understood from an operational point of view, so by modeling FTL concepts directly on top of Kube teams will already be familiar with the underlying infrastructure.

This approach also means that we can focus on creating value for developers, rather than re-inventing the wheel by recreating our own implementations of things that Kube already provides.

## Goals

- FTL will switch to relying on Kube to provide as much basic infrastructure as possible
- Where possible we should still avoid having Kube API usage directly in the core, however some abstraction leakage is probably inevitable

### Non-Goals (optional)

- We are not ruling out adding additional platforms at a much later date
- Local development will not require Kube

### Required changes (how)

In the very short term the following changes will be required, however longer term this will affect the core architecture and may result in many changes.

- Remove load balancing via the controller and delegate to a Service
- Simplify runner registration protocol to allow health checks to work correctly