---
title: "Introducing TrinoHub: Our Open Source Control Plane for Trino on AWS"
url: "https://bitrefinery.com/blog/introducing-trinohub-open-source-trino-control-plane-for-aws"
description: "Bit Refinery has open-sourced TrinoHub, the self-hosted AWS control plane we built to run Trino SQL clusters for our customers. Provision, autoscale, and query EC2-backed Trino clusters from your browser — with no static AWS credentials anywhere. Apache-2.0 licensed and available now on GitHub."
author: "Bit Refinery Team"
date: "2026-07-12"
lastmod: "2026-07-12"
tags: ["trino", "open source", "aws", "sql", "data analytics"]
source: "blog CMS"
---

# Introducing TrinoHub: Our Open Source Control Plane for Trino on AWS

For the past while, we've been running [Trino](https://trino.io/) clusters in our data centers and on AWS for several of our customers. Trino is a phenomenal distributed SQL engine — but standing up and operating clusters the traditional way meant a pile of Terraform modules, Ansible playbooks, and tribal knowledge about instance sizing, scaling, and credential hygiene. So we built ourselves a control plane to make it painless.

Today we're excited to share it with everyone. **[TrinoHub](https://github.com/BitRefinery/trinohub)** is now fully open source under the Apache-2.0 license.

## What is TrinoHub?

TrinoHub is a self-hosted AWS control plane for running Trino SQL clusters from the browser. It ships as a single EC2 instance — a FastAPI application with SQLite storage and a static, no-build-step frontend — deployed in one command via CloudFormation. From that one instance, platform engineers launch and operate separate EC2-backed Trino clusters, while analysts write SQL against them without ever touching the AWS console.

![TrinoHub architecture — browser UI, control plane, EC2-backed Trino clusters, and S3/Glue catalogs](/api/storage/files/blog-images/blog-1783864510489-trinohub-architecture.png)

## Why we built it

Every Trino deployment we managed followed the same pattern: provision a coordinator, template the workers, wire up autoscaling, lock down security groups, and carefully avoid scattering AWS keys across configs. Doing that with general-purpose infrastructure tooling works, but it's slow to stand up, easy to get subtly wrong, and completely opaque to the analysts who just want to run queries.

TrinoHub folds all of that operational knowledge into one purpose-built tool:

- **One-command deployment.** A CloudFormation stack creates the IAM roles, security groups, and the control-plane instance. No manual credential setup.
- **UI-driven cluster operations.** Create, start, resume, suspend, disable, and delete clusters from the browser. Every AWS resource is tagged and tracked per cluster.
- **Sensible instance presets.** Cost, Balanced, and Power tiers map to M-family EC2 types with automatic fallbacks — no more spreadsheet of instance types.

## A Trino-aware autoscaler

Generic CPU-based autoscaling doesn't understand SQL workloads. TrinoHub's control loop watches what actually matters — queued queries alongside CPU — and scales worker Auto Scaling Groups with cooldown periods so clusters don't thrash. Idle clusters auto-suspend, and a suspended cluster resumes simply by querying it. You pay for compute when queries are running, not around the clock.

## Query from the browser

TrinoHub isn't just for operators. It includes a full query environment for analysts:

- **SQL editor** with a schema browser, cluster/catalog/schema selectors, live status polling, and tabular results (capped at 1,000 rows / 10 MB to keep the UI honest), plus CSV export.
- **Notebooks** in the Jupyter/Databricks style — ordered SQL cells with inline tables and charts, and per-cell cluster, catalog, and schema overrides.

Out of the box you get the built-in `system`, `tpch`, and `tpcds` catalogs for testing and benchmarking, plus first-class integrations for Amazon S3 and AWS Glue (Iceberg) for your real data.

## Security by default

This is the part we're most opinionated about: **TrinoHub never stores static AWS credentials.** Everything authenticates through EC2 instance profiles — the control plane provisions with its own role, and workers reach S3 through their own IAM roles, so there are no access keys to rotate or leak.

On top of that:

- The UI enforces a CIDR allowlist at the application layer.
- Cluster nodes enroll using signed, per-cluster bootstrap tokens.
- Passwords are hashed and sessions use httpOnly cookies.
- Two clean roles: **Admin** for setup and operations, **Analyst** for query execution.

## Getting started

The recommended path is the CloudFormation deployment — one command with your VPC, subnet, and allowed CIDR, then a browser-based setup wizard. For local development, it's a standard Python virtualenv:

```bash
git clone https://github.com/BitRefinery/trinohub.git
cd trinohub
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
uvicorn trinohub.api:app --host 0.0.0.0 --port 8000
```

Local development runs against in-memory AWS and Trino fakes, so you can explore the whole product without provisioning anything. The repo includes getting-started guides, cluster management docs, a security model writeup, and an end-to-end test suite.

## Scope, on purpose

TrinoHub is deliberately focused: AWS, EC2, and Trino. Multi-cloud, Kubernetes, and OAuth are explicitly out of scope. We'd rather do one deployment model extremely well than do five of them halfway.

## Get involved

TrinoHub is Apache-2.0 licensed and ready to use today:

- ⭐ Star and explore the repo: [github.com/BitRefinery/trinohub](https://github.com/BitRefinery/trinohub)
- 🐛 Found an issue or have a feature idea? Open an issue or a pull request — contributions are welcome.

And if you'd rather have someone run Trino for you — that's literally how TrinoHub came to exist — check out our [Trino consulting services](/services/trino-consulting) or [get in touch](/#contact). We'd love to hear what you build with it.
