Public Beta

Expose localhost to the internet in one command.

Share dev servers, webhook handlers, and internal tools over HTTPS - no port forwarding, no VPNs.

One command
cruma http localhost:3000
→ https://random-id.tun.cruma.io

A free tier stays available (with slower tunnels). During the beta, features and limits will evolve as we learn from real-world use, but the core idea - simple tunnels with the option for end-to-end encryption - will stay the same.

Download the agent See comparison
Cruma tunnel flow graph overview
Cruma terminal UI showing tunnel status

Why Cruma

Cruma is a tunneling service for developers, small teams, and homelabs who want fast setup, terminal-first tooling, and the option for end-to-end encryption when using their own domain.

Zero setup

Share in one command

Get a public HTTPS URL for localhost without touching DNS, port forwarding, or VPNs.

Terminal-first

Manage tunnels locally

Stay in your CLI and TUI to configure, launch, and monitor tunnels without a heavyweight cloud dashboard.

User-controlled TLS

Keep encryption end-to-end

Bring your own domain and terminate TLS on the agent so payloads never decrypt at cruma.io.

Built for homelabs

Simple and affordable

Focused feature set that stays lightweight for individual developers and small teams.

Use cases

Concrete ways people use Cruma today, from demos to webhook testing.

Multiple services in one config

Define several hostnames and start them together.

 # Multiple services
 cruma config add http localhost:3000 --hostname dev
 cruma config add https example.com:443 --hostname example-site
 cruma start

How encryption works

By default we terminate TLS at our edge and issue certificates for cruma.io subdomains. If you add a CNAME and use your own domain, you can terminate TLS yourself on the agent (or behind your own reverse proxy) for end-to-end encryption; in that mode Cruma only sees control-plane metadata.

We’re intentionally not building a full enterprise edge platform: there is no bundled SSO suite, no complex policy engine, and no formal SLA. Today we run two PoPs - EU-North (FI) & US-East; agent maintains at least one HTTP/2 channel and one QUIC channel to the closest region, with automatic reconnects on failure.

The client isn’t open source yet, but we intend to open source it as the platform stabilizes and the protocol surface settles.

Roadmap

Planned work as the beta matures.

Planned

Kubernetes ingress

Ship a Cruma Ingress controller so cluster services get HTTPS endpoints automatically exposed through cruma.io

In progress

Local Web UI

Improve the local web UI for configuring and managing tunnels directly from your machine.

Planned

Cruma SDK

Let applications create tunnels programmatically for ephemeral preview environments.

Downloads

Pick your platform to install the latest tunnel agent.

Windows Agent

Downloading the tunnel agent

During the beta phase we do not ship a Windows installer; instead we provide a direct download link to the latest binary: cruma.exe


Prefer automation? Open PowerShell and run the installation script:

irm https://cruma.io/cruma.psm1 | iex ; Install-CrumaTunnel

You can uninstall with:

irm https://cruma.io/cruma.psm1 | iex ; Uninstall-CrumaTunnel
Run with Powershell

Getting started

Once installed, you can run it directly in your preferred terminal:

cruma

On first run you’ll see a TUI-based wizard to help you set things up; follow the instructions to complete the setup. You can also run cruma --help to see all available options.


For more detailed documentation, visit our documentation.

We plan to distribute the Windows agent through additional channels such as WinGet as the beta matures.

Comparison

Cruma is a focused tunnel for developers, small teams, and homelabs. We optimize for fast setup, terminal-first tooling, and privacy options rather than enterprise policy suites. By default Cruma terminates TLS at our edge. If you bring your own domain via CNAME, you can terminate TLS yourself on the agent (or your own proxy) for end-to-end encryption; in that mode Cruma only sees control-plane metadata. Below is a high-level comparison with Cloudflare Tunnel and ngrok based on their publicly documented features.


Legend: ✓ Available · ~ Limited or requires extra configuration · $ Available on paid plans · ✕ Not available / not documented
Feature Cruma Cloudflare Tunnels ngrok
Account-free quick tunnels
✓
Yes Anonymous mode is available for quickly setting up tunnels without an account. Anonymous tunnels are more aggressively rate-limited to ensure fair usage.
✓
Yes Cloudflare supports this through “Quick Tunnels”, available at trycloudflare.com. These are also aggressively rate-limited but can be relaxed by signing up for a free account.
✕
No Requires an account and auth token.
Custom domains with end-to-end encryption
✓
Yes Create a CNAME record pointing to your tunnel’s assigned domain name. Once the agent is configured to handle traffic for that domain, it will terminate TLS locally and forward traffic to your application.
✕
No (for end-to-end) Cloudflare supports custom domains, but HTTP(S) traffic terminates at Cloudflare’s edge using Cloudflare-managed certificates. Cloudflare can see plaintext traffic at that point, so it is not strictly end-to-end encrypted between client and your origin.
$
Paid Custom domains are available on ngrok’s paid plans (see pricing for current tiers).
Multi-endpoint
✓
Yes You can serve any number of endpoints using different hostnames.
✓
Yes You can serve any number of endpoints using different hostnames.
$
Paid You can serve any number of endpoints using different hostnames, but only on paid plans.
Protocol forwarding
~
TCP Currently only TCP forwarding is supported, but UDP forwarding is on the roadmap.
✓
TCP & UDP cloudflared supports UDP forwarding modes (Warp/QUIC proxies require Zero Trust setup).
~
TCP ngrok’s public service currently supports TCP forwarding
Agent uplink protocols
✓
QUIC + HTTP/2 Agents maintain TLS-encrypted QUIC and HTTP/2 sessions to the network to reduce latency and improve resilience.
✓
QUIC + HTTP/2 cloudflared can use QUIC uplinks and HTTP/2 over TLS in supported configurations.
~
HTTP/2 ngrok agents speak HTTP/2 to ngrok’s control plane; no QUIC uplink seems to be supported or planned today as of their public documentation.
Local UX & tooling
✓
TUI + local-only web UI The agent includes a localhost-only web UI for configuration and request inspection, plus a terminal-based TUI for quick actions. It can also run in headless mode without the TUI.
~
CLI + hosted dashboard cloudflared is configured via CLI and Cloudflare’s Zero Trust dashboards; there is no full-featured local web UI for managing tunnels.
~
CLI + remote inspector ngrok’s request inspector and many configuration options are accessed via their cloud dashboard, rather than a self-hosted or purely local UI.
HTTP request inspection
✓
Local UI HTTP request inspection is available in both the TUI and the local web UI; request logs never leave your machine.
~
Zero Trust dashboards Requires routing through Cloudflare’s edge so logs live in their SaaS; there is no local inspector.
✕
Remote-only ngrok’s primary inspector UI runs in their cloud dashboard. They do not provide a fully self-hosted equivalent for the public service.
Serve local directories
✓
Built-in directory server You can serve a local directory directly from the agent, without needing nginx or another HTTP server for simple static content.
✕
No built-in static server You run your own web server or use other Cloudflare products (e.g. Pages/Sites); cloudflared itself does not serve local directories as a static file server.
✕
No built-in static server You must run a local server yourself and point ngrok to it; ngrok does not ship an integrated directory server helper.
Built-in access controls
✓
IP allow-lists, forms & API keys Configure a list of allowed source IPs per tunnel (enforced at cruma.io so unexpected traffic never reaches your device), or put form-based auth or header API-key enforcement in front of directory servers or any HTTP(S) backend.
~
Via Zero Trust policies HTTP access control is typically configured through Cloudflare Access and Zero Trust policies, managed in Cloudflare’s SaaS control plane rather than purely in the local agent.
$
Paid ngrok offers access control and traffic-shaping features on paid plans (see pricing for current availability).
End-to-end encryption
✓
Supported For CNAME’d domains, TLS can terminate on the locally running agent, so Cruma’s servers only see control-plane metadata and encrypted payloads. TLS passthrough is also supported if you already have TLS-terminated services.
✕
Not provider-blind For standard HTTP(S) tunnels, TLS terminates at Cloudflare’s edge using their certificates, so Cloudflare can access plaintext traffic at that point. You can add additional encryption between Cloudflare and your origin, but Cloudflare remains in the trust chain.
✓
Supported ngrok supports TLS passthrough to your origin and agent-side TLS termination, allowing you to keep TLS keys local while still using ngrok’s routing.

ngrok is closest to Cruma in terms of tunnel and security capabilities. Cruma’s main differentiators are terminal-first tooling, simpler setup for non-specialists, and a pricing model that aims to stay affordable for individual developers and small teams.

Comparisons are based on publicly documented capabilities as of Q1 2026. If you spot an error or something has changed, email [email protected] and we’ll update this table.