Trino Gateway

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B4ms (4 vCPU / 16 GiB RAM) is a good starting size. Both the gateway and the bundled Trino are JVM services, so scale up for higher concurrency and larger workloads.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp for the dashboard and the query endpoint. For public exposure, front the VM with TLS (see Enabling HTTPS).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Trino Gateway by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

Alternatively, deploy with the Azure CLI. Replace the values in angle brackets:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:trino-gateway-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name trino-gateway \
  --image sac1647283583153:trino-gateway-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name trino-gateway --port 80 --priority 1010

Step 3 - Connect to your VM

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

Check that all five services are active:

systemctl is-active postgresql.service trino.service trino-gateway.service trino-gateway-register.service nginx.service

All five report active. Both the gateway and the bundled Trino are JVM services, so they take around 30 to 60 seconds after boot to finish starting. The gateway then routes queries as soon as its backend passes a health check.

The gateway (127.0.0.1:8080) and the bundled Trino (127.0.0.1:8081) are bound to loopback. Only nginx on :80 is exposed publicly.

Step 5 - Retrieve your dashboard password

The first boot of your VM generates a unique admin password and writes it to a root-only file. Read it with:

sudo cat /root/trino-gateway-credentials.txt

The file contains gateway.user (admin) and gateway.password, plus the dashboard URL. The same per-VM password is used for both the gateway dashboard login and the nginx Basic-auth wall on the query path.

The gateway's PostgreSQL role also gets its own per-VM password. It is injected into the running service and never baked into the shipped image. Store the admin password somewhere safe.

Step 6 - Check the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes. Query it:

curl -s http://localhost/health

The endpoint returns ok.

Step 7 - Open the Trino Gateway dashboard

Browse to http://<vm-public-ip>/ and sign in as admin with the password from Step 5. The dashboard summarises the routing fleet. It shows how many backends are registered, online and healthy, plus queries per hour and a query-distribution chart.

Open the Cluster view to see the registered Trino backend the gateway routes to. This is the bundled single-node coordinator, with its routing group (adhoc) and its proxy address.

Step 8 - Send a query through the gateway

A standard Trino client points straight at the gateway's endpoint, and the gateway transparently forwards the query to a healthy backend. The bundled tpch catalog exposes the standard TPC-H schemas (tiny, sf1 and others), so you can query real sample data with no external data source.

Run a query through the gateway (port 8080) with the bundled CLI:

/opt/trino/bin/trino --server http://127.0.0.1:8080 --user admin --catalog tpch --schema tiny --execute 'SELECT count(*) FROM nation'

The query returns 25. Trino Gateway routed it to the bundled Trino coordinator and back. The nginx Basic-auth wall guards the same query path off-host, and the gateway dashboard has its own per-VM login. The image ships no default admin.

Next, try a richer query that totals order value by market segment, routed through the gateway:

/opt/trino/bin/trino --server http://127.0.0.1:8080 --user admin --catalog tpch --schema tiny --execute "SELECT c.mktsegment, round(sum(o.totalprice), 2) AS revenue FROM orders o JOIN customer c ON o.custkey = c.custkey GROUP BY c.mktsegment ORDER BY revenue DESC"

Step 9 - View routed-query history

The gateway records every query it routes in its PostgreSQL history store. Inspect the registered backend and the recorded routing history directly:

sudo -u postgres psql -d trinogateway -c "SELECT name, routing_group, backend_url, active FROM gateway_backend"

sudo -u postgres psql -d trinogateway -c "SELECT to_char(to_timestamp(created/1000),'HH24:MI:SS') AS at, user_name, backend_url, left(query_text,40) AS query FROM query_history ORDER BY created DESC LIMIT 5"

You can also browse the same history in the dashboard's History tab. Each row shows the routing group, the backend the query was routed to, the user, the client source and the SQL text.

Step 10 - Add more Trino clusters and routing groups

Trino Gateway is designed to sit in front of many Trino clusters. To add another backend, register it through the gateway's admin API (sign in to obtain a session token), or add it in the dashboard's Cluster view.

Backends are grouped by routing group. A client can target a group with the X-Trino-Routing-Group header, and requests with no header fall to the default adhoc group. The Routing rules view controls how requests map to groups.

Point a new cluster's proxyTo at its coordinator URL and set active: true. The gateway health-checks each backend through its v1/info endpoint and only routes to healthy clusters. You can drain a cluster for maintenance by marking it inactive, without dropping client connections.

Step 11 - Connect BI tools and applications

The gateway speaks the standard Trino client protocol. Most BI and analytics tools therefore connect through the official Trino JDBC/ODBC drivers or a native Trino connector, pointed at the gateway rather than at an individual cluster.

Point the client at the VM on port 80 and select the tpch catalog, or any catalog you add to a backend. For example, the JDBC URL is:

jdbc:trino://<vm-public-ip>:80/tpch/tiny

Tools such as DBeaver, Superset, Tableau, Power BI and Metabase all connect this way. For production use, terminate TLS in front of nginx (see Enabling HTTPS) and use jdbc:trino://<host>:443/... with SSL enabled.

As you add real Trino clusters behind the gateway, clients keep using this one endpoint. The gateway load-balances across the healthy backends.

Enabling HTTPS

The nginx reverse proxy terminates plain HTTP on port 80. For public exposure, put a certificate in front of it. Add a DNS name for the VM, then do one of the following:

• Use the companion SecureAnyCloud nginx-ssl-certbot image as a TLS reverse proxy.
• Install certbot and extend the existing nginx site with a listen 443 ssl; server block and your certificate paths.

Keep the gateway and the bundled Trino bound to loopback, so the only public surface is the authenticated, TLS-terminated proxy.

Maintenance

• Gateway configuration: the gateway config lives at /etc/trino-gateway/config.yaml (datastore, health monitor, authentication). The per-VM DB password is injected from /etc/trino-gateway/gateway.env. Edit the file, then run sudo systemctl restart trino-gateway to apply changes.
• Bundled Trino configuration: Trino's config is under /opt/trino/etc/, and catalogs live in /opt/trino/etc/catalog/. Edit the files, then run sudo systemctl restart trino.
• Adding backends: register additional Trino clusters through the gateway (Step 10). The routing state is persisted in PostgreSQL and survives restarts.
• Backups: back up the trinogateway PostgreSQL database, which holds the routing config and query history.
• Upgrades: replace /opt/trino-gateway/gateway-ha.jar (or /opt/trino) with a newer release that matches the required JDK, and restart the service.
• Security patches: unattended-upgrades stays enabled, so the OS keeps receiving security updates automatically.

Support

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.

Trino and Trino Gateway are trademarks of the Trino Software Foundation. SecureAnyCloud produces this image, and it is not affiliated with or endorsed by the Trino project. Trino and Trino Gateway are distributed under the Apache License 2.0.

Deploy on Azure

Launch Trino Gateway on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need help?

Our support team is available 24/7.

sales@secureanycloud.com