No hardware? Rent a small VM, paste one bootstrap, and have your own Talon Studio behind TLS in about fifteen minutes, in your own cloud account.
What this is
This page is for people who want to run Talon Studio and have no machine to run it on. It is not a hosted service: Talon Labs operates no infrastructure for Talon Studio and holds none of your detections, log samples or SIEM credentials. What you end up with is your own appliance, on a VM in your own account, that you patch and back up.
The bootstrap is a cloud-init file published on this site. VPS providers run cloud-init on first boot — it is the box labelled "user data" when you create a server — so the same file works on Hetzner, DigitalOcean, Vultr, Linode, AWS EC2, Azure and the rest. The hosting guide compares providers.
Pick a machine
1
Create a DNS A record for the name you will use, e.g. studio.example.com, pointing at the server's IP. Do this first: the bootstrap gets a TLS certificate on first boot, and cannot for a name that does not resolve to the machine yet. On Hetzner, allocate a Primary IP first and attach it to the server.
2
Create the server — 2 vCPU and 4 GB RAM, on Debian 13 or Ubuntu 24.04. A Hetzner CX22 (2 vCPU, 4 GB, 40 GB disk) is the value pick; a CX32 if you replay large scenarios or keep a lot of synced content. On DigitalOcean, a Basic Droplet with 2 vCPU / 4 GB.
3
Paste the bootstrap into the user-data box, with its placeholders filled in (next section).
It is commented plain text; read it before you paste it. Replace the four placeholders:
__DOMAIN__
The name from your DNS record, e.g. studio.example.com.
__ADMIN_EMAIL__
The first admin's email, and where Let's Encrypt sends expiry warnings.
__SSH_KEY__
Your full public key line, e.g. ssh-ed25519 AAAA… you@laptop.
__IMAGE_TAG__
A pinned release, e.g. v1.0.2-beta. Moving tags — latest, beta, edge — are refused, so rollback stays possible.
Leave a placeholder in and the install stops with a message naming it rather than coming up half-configured. There is no admin password to choose: the appliance generates one on first boot, so it never sits in user data. Allow about ten minutes — first boot initialises Postgres and syncs detection content — and watch it:
The image, ghcr.io/talon-labs-detection-platform/talon-studio, is public, so the bootstrap's pull needs no login and the bootstrap carries no registry token. If the install stopped part-way, sudo /etc/talon/install.sh on the server runs it again: it keeps the secrets it generated the first time and picks up where it stopped.
First sign-in
1
Take the encryption key out first and put it in your password manager: ssh talon@<ip> 'sudo cat /root/talon-credentials.txt'. TALON_ENCRYPTION_KEY encrypts every credential the appliance stores — SIEM connections, API keys, Git tokens. Lose it and a restored /data volume does not help you: what is in it is ciphertext.
Openhttps://studio.example.com and sign in as admin, or with the email you gave. Choose a new password when asked.
4
Paste your Community key on the key screen that follows — the Talon Studio key from your Talon Labs account — then create your workspace.
What you end up with
Docker, and a ufw firewall that denies everything inbound except SSH, 80 and 443. Port 80 is open for the certificate challenge and redirects to 443.
Caddy on the host, with a Let's Encrypt certificate for your domain, proxying to the appliance on 127.0.0.1:3000 — the only way in.
The appliance in /opt/talon-studio: a compose file and a mode-0600 .env with the image you pinned, NEXTAUTH_URL, TALON_TRUST_PROXY=true, TALON_STRICT_SECURITY=true, and its own generated AUTH_SECRET, TALON_ENCRYPTION_KEY, TALON_METRICS_TOKEN and database password.
A copy of those secrets in /root/talon-credentials.txt, readable by root only.
The key is in .env here, not on the volume
The bootstrap generates the secrets into /opt/talon-studio/.env, so on this route TALON_ENCRYPTION_KEY is not in /data/secrets. A backup of the volume alone cannot be decrypted — keep the key, or the .env, with it.
Terraform instead
Four stacks are published as module archives, so there is nothing to clone:
vm-aws
EC2, an EBS volume, a security group and an Elastic IP, bootstrapped by the same cloud-init.
vm-azure
A Linux VM, a managed disk, an NSG and a static public IP, with the same cloud-init.
kubernetes-aws
EKS, RDS Postgres, and the Helm chart from this site.
kubernetes-azure
AKS, Postgres Flexible Server, and the Helm chart from this site.
Each is at https://www.talonlabs.dev/studio/terraform/<stack>.tar.gz, with a README beside them. The VM stacks fetch the same bootstrap; set cloud_init_sha256 and the plan fails if what comes back is not what you reviewed. The Kubernetes stacks put the encryption key in Terraform state, so encrypt that backend and restrict who can read it.
Written ahead of first apply
The stacks were cross-checked against the provider schemas and the chart's values, but none has yet been applied against a live account. Expect first-apply fixes — a provider pin, an AMI filter, a quota — and apply one stack before the next.
Managed platforms
A managed container platform works if it can do three things: keep one container running from the image, attach a persistent disk at /data (20 GB to start), and give the first boot time — it initialises Postgres and syncs content, so allow a health-check timeout of several minutes on /api/health. A platform that sleeps idle services or scales to zero will not do.
Set NEXTAUTH_URL to the URL the platform gives you, and TALON_TRUST_PROXY=true when its router sets X-Real-IP to the client's address — Studio reads that header before X-Forwarded-For, so a router that passes a client's own through lets it name its address.
Leave the secrets unset to have them generated onto the disk, or set them in the platform's secret store with openssl rand -hex 32 — and keep a copy of TALON_ENCRYPTION_KEY outside the platform either way.
The first admin's generated password is printed once in the deploy log. If you cannot read the log or the disk, set a strong TALON_ADMIN_PASSWORD instead, with TALON_ADMIN_FORCE_PASSWORD_CHANGE=true.
Afterwards
Backups are yours. The /data volume is the whole appliance; Backup & Restore has the commands. A provider disk snapshot of a running machine is not a consistent database copy — take the volume backup as well.
Upgrades are a tag change: edit TALON_STUDIO_IMAGE in /opt/talon-studio/.env, then sudo docker compose -f /opt/talon-studio/docker-compose.yml pull and up -d. Upgrading has the checks.
The OS is yours too. Plan on patching it; that is the hour a month the managed platforms charge for.