Tela + Awan Saya Business Plan
Executive summary
What Tela is
Tela is an open-source tool that gives users secure access to TCP services — SSH, RDP, databases, HTTP, anything TCP — through an encrypted WireGuard tunnel relayed over WebSocket. It is written in Go and ships as three single-binary components: a client (tela), a daemon (telad), and a hub server (telahubd).
The client and daemon each create a userspace WireGuard tunnel using gVisor netstack. This is pure Go, no kernel module, no TUN/TAP device, no admin privileges. The hub sits between them and relays opaque WireGuard ciphertext — it never sees plaintext. After the initial WebSocket connection, Tela automatically negotiates faster transports (UDP relay, then direct peer-to-peer) when network conditions allow.
The problem Tela solves
Remote access to systems behind NAT and firewalls is a common need and a persistent pain point. The existing options each have significant drawbacks:
- VPNs and mesh VPNs (WireGuard, Tailscale, ZeroTier, Nebula) require admin privileges, kernel modules or TUN devices, and often grant broader network access than necessary. Corporate endpoints frequently block the driver installs these tools need.
- Bastion / jump hosts add infrastructure, create operational choke points, and still require inbound firewall rules.
- HTTP tunnels (ngrok, Cloudflare Tunnel) work well for web traffic but are awkward or impossible for raw TCP services like SSH, RDP, and databases.
- Large zero-trust platforms (Teleport, Zscaler) are powerful but heavy, expensive, and overkill for small and mid-sized teams.
Tela occupies a gap none of these fill well: protocol-agnostic TCP tunneling with end-to-end encryption, no admin privileges, and outbound-only connectivity on both ends.
What makes Tela unique in the FOSS space
Several FOSS tools address pieces of this problem. None combine all of Tela's properties:
| Property | Tela | WireGuard | Chisel | frp / rathole | bore | Teleport |
|---|---|---|---|---|---|---|
| No admin / no TUN device | Yes | No | Yes | Yes | Yes | Partial |
| End-to-end encryption (relay is blind) | Yes | N/A (point-to-point) | No (TLS terminates at relay) | No | No | No |
| Protocol-agnostic TCP | Yes | Yes (full IP) | Yes | Yes | Yes | No (SSH, K8s, DB only) |
| Outbound-only on both ends | Yes | No | No (server needs inbound) | No (server needs inbound) | No (server needs inbound) | No |
| Automatic transport upgrade (WS → UDP → P2P) | Yes | No | No | No | No | No |
| Hub-spoke with RBAC | Yes | No | No | Partial | No | Yes |
The blind relay is the key architectural distinction. In most tunnel/relay tools, the relay either terminates TLS (seeing plaintext) or provides no encryption beyond the transport layer. Tela's hub relays WireGuard ciphertext — Curve25519 key exchange, ChaCha20-Poly1305 encryption — and has no access to session content. This means the hub can be hosted by a third party (including Awan Saya) without compromising the confidentiality of the traffic passing through it.
The zero-admin, outbound-only model is the key operational distinction. Both the client and the daemon make outbound connections to the hub. Neither needs inbound ports, firewall rules, or elevated privileges. This makes Tela deployable in environments where other tools cannot be installed: locked-down corporate laptops, customer networks an MSP doesn't control, IoT devices in the field.
The elevator pitch for Awan Saya
Awan Saya is to Tela what GitHub is to git.
Tela is the connectivity fabric — open source, self-hostable, works standalone. Awan Saya is the platform layer that adds multi-hub visibility, hub discovery, hosted infrastructure, and (eventually) centralized access control. It is a hosted service at awansaya.net.
Specifically, Awan Saya provides:
- Hub directory and name resolution — users run
tela machines -hub myhubinstead of memorizing URLs - Multi-hub dashboard — one portal showing fleet-wide status, machine inventory, and connection history across all registered hubs
- Hosted hubs and relay endpoints — Awan Saya runs hubs on behalf of users who don't have (or don't want to maintain) their own infrastructure
- User management and personal API tokens — centralized identity for CLI authentication
- Future: SSO, RBAC, audit logging — enterprise governance features
Tela works without Awan Saya. Awan Saya makes Tela easier to adopt, easier to scale, and easier to manage — and that's what people pay for.
Awan Saya's dependency on Tela adoption
Awan Saya's commercial success depends on Tela gaining meaningful adoption in its niche. No Tela users means no Awan Saya customers. This is the central risk and the central strategic question.
How likely is Tela to gain traction?
The honest answer: possible but not guaranteed, and it depends almost entirely on execution rather than technology.
Factors working in Tela's favor:
- The niche is real and underserved. The combination of no-admin, no-driver, outbound-only, end-to-end encrypted, protocol-agnostic TCP tunneling has no direct FOSS competitor. People searching for “SSH tunnel without admin” or “access RDP behind NAT without VPN” are looking for exactly this and have limited options.
- Developer tools spread through word of mouth. A tool that solves a real pain point for one person on a team tends to spread to the rest of the team. Tela's zero-install client makes this particularly frictionless — there's nothing to ask IT to approve.
- The open-source model builds trust. Security tools face a higher trust bar. Being open-source, single-purpose, and auditable lowers that bar. The blind relay architecture is independently verifiable — anyone can confirm the hub handles only ciphertext.
- Low switching cost for users. Tela doesn't replace a network stack or require rearchitecting anything. It slots in alongside existing tools. Users can try it on one machine in an afternoon.
- The MSP and IoT use cases have built-in distribution. An MSP that adopts Tela for one client deploys it to all their clients. An IoT vendor that embeds
teladships it to every device.
Factors working against Tela:
- Awareness is the biggest problem. The tool doesn't exist in anyone's mental map yet. Tailscale has brand recognition and $100M+ in funding. ngrok is a household name among developers. Tela is unknown.
- Security tools need reputation. Enterprises and security-conscious teams are reluctant to adopt tools without a track record, third-party audits, or community validation. This takes time.
- The “good enough” problem. Many potential users have a workaround that's tolerable (SSH tunnels, clunky VPN, asking a colleague to proxy). Tolerable workarounds are the biggest competitor for any new tool.
- Solo maintainer risk. A single-maintainer FOSS project carries bus factor concerns. Potential adopters may hesitate to depend on it.
What it takes to get there:
- Content that meets people at the point of pain. Blog posts, tutorials, and docs targeting specific search terms: “access SSH behind NAT without VPN,” “RDP tunnel without admin rights,” “remote access for IoT devices.” This is the primary growth lever for a solo-founder FOSS project.
- A Hacker News / Reddit launch. One well-timed Show HN post with a clear, honest description can generate the initial wave of awareness. The tool needs to be polished enough that the first impression lands.
- Conference talks and demos. Live demos of “connect to a machine behind NAT in 30 seconds with no setup” are compelling. DevOps, security, and MSP conferences are the right venues.
- Case studies and testimonials. Even one real-world “we replaced our bastion with Tela” story is worth more than any feature list.
- Packaging and distribution. The starter Docker image, pre-built binaries (already shipping via GitHub Releases), and eventually package manager entries (Homebrew, apt, winget) reduce friction to near zero.
- Community building. GitHub Discussions or a Discord for early adopters. Responsive issue triage. Accepting contributions. The first 50 engaged users matter more than the first 5,000 drive-by visitors.
- A security review. Even an informal one from a respected community member or a self-published audit of the WireGuard integration adds credibility. A formal audit is expensive but becomes worthwhile if traction develops.
Realistic assessment: Tela is unlikely to become a mainstream tool on the scale of Tailscale or ngrok — those have venture funding, full-time teams, and years of brand building. But it doesn't need to. Awan Saya's revenue model works at much smaller scale. The conservative revenue projection (500 free users, 15 Pro, 2 Business at Year 1) requires Tela to be known and trusted by a few hundred people, not millions. That's achievable with consistent content, good packaging, and a bit of luck on timing and visibility.
The key risk is not that Tela fails technically — it already works — but that it fails to reach the people who need it. Everything in the list above is about distribution, not features.
Key architectural insight for pricing
Awan Saya's costs have two distinct drivers:
- Portal activity (hub polling, dashboard serving, API calls, history storage) — scales with the number of registered hubs but is low per hub. This applies to all self-hosted hubs.
- Hosted infrastructure (compute, bandwidth, relay traffic) — applies only to hubs that Awan Saya runs on the user's behalf (Model C) or relays traffic for (Model B). See Tela DESIGN.md §18.1 for model definitions.
For self-hosted hubs (Model A), the marginal cost to Awan Saya is negligible. For hosted hubs and relay endpoints, real infrastructure cost exists but is modest: each hub is a single Go process with a small memory footprint, and relay traffic is just forwarding opaque WebSocket frames. Multiple hosted hubs share a single host efficiently.
This dual cost model means the free tier can be generous with portal features (where marginal cost is near zero) while also offering a small but real hosted-hub allocation (where the cost is small but nonzero). Hosted hub tier limits reflect actual infrastructure cost rather than artificial scarcity.
The value Awan Saya adds on top of free Tela:
- Hub directory and short-name resolution (convenience)
- Centralized multi-hub dashboard (visibility)
- Hosted hubs and relay endpoints (infrastructure — eliminating self-hosting overhead)
- Starter hub image (fast on-ramp for self-hosters)
- Future: cross-hub SSO, user management (governance)
Deployment gradient
Not everyone wants the same level of operational involvement. Awan Saya supports a gradient from fully managed to fully DIY:
| Model | Who runs the hub | Networking setup | Target audience |
|---|---|---|---|
| Hosted hub (Model C) | Awan Saya | None — stable URL provided | Individuals and teams with no server infrastructure |
| Self-hosted + relay (Model B) | User | None — hub connects outbound to Awan Saya relay | Users with a machine but no public IP, Cloudflare, or DNS |
| Starter hub image | User | User provides TLS termination (Cloudflare Tunnel, Caddy, etc.) | Users comfortable with Docker who want fast setup |
| Build from source (Model A) | User | Full DIY | Power users, contributors, air-gapped environments |
The starter hub image and relay endpoints lower the barrier between “I need Awan Saya to host everything” and “I'll build from source and manage my own networking.” Each step down the table trades convenience for control.
Starter hub image
A pre-built Docker image containing telahubd with sensible defaults, so someone can docker run or docker compose up with minimal configuration (set a hub name, generate a token, done).
What's in the image
telahubdbinary (matches the latest release)- Minimal Alpine base
- Default config: port 8080, UDP 41820,
HUB_NAME/TELA_OWNER_TOKENconfigurable via environment variables - A bundled
docker-compose.ymlexample showing TLS termination via Caddy (or Cloudflare Tunnel) - The hub console (web UI) served at
/
Where it lives
The image should be available through multiple channels — each serves a different discovery path:
| Channel | What | Who it serves |
|---|---|---|
GitHub Container Registry (ghcr.io/paulmooreparks/telahubd) |
Published automatically by CI on each release | DevOps and infra people who know Docker |
Docker Hub (paulmooreparks/telahubd) |
Mirror of the ghcr.io image | Broader discoverability (docker search telahubd) |
Tela repo (docker/ directory) |
Dockerfile + docker-compose.yml + docs | Contributors, developers who've already cloned the repo |
| Awan Saya site (guided setup page) | Links to the image, provides a copy-paste docker-compose.yml snippet, optional web form that generates a customized compose file with pre-filled hub name and token |
Non-technical or first-time users who found the product through the website |
All four channels point at the same image. The CI pipeline builds once and pushes to both registries. The Awan Saya site links to the registries and adds guided setup on top.
Quick-start experience
# Pull and run (one command)
docker run -d --name myhub \
-e HUB_NAME=myhub \
-e TELA_OWNER_TOKEN=$(openssl rand -hex 32) \
-p 8080:8080 -p 41820:41820/udp \
ghcr.io/paulmooreparks/telahubd:latest
# Or with the bundled docker-compose.yml
curl -O https://raw.githubusercontent.com/paulmooreparks/tela/main/docker/docker-compose.yml
# Edit .env with your hub name and token
docker compose up -d
Then optionally register with Awan Saya for name resolution and dashboard visibility:
telahubd portal add awansaya https://awansaya.net
Or skip Awan Saya entirely — the hub works standalone.
Relationship to hosted hubs
The starter image and hosted hubs are not competing features. They serve different points on the convenience/control spectrum:
- Hosted hub: “I don't want to run anything. Give me a URL.” — Awan Saya operates the hub.
- Starter image: “I have a machine and Docker. Get me running in 5 minutes.” — the user operates the hub but skips the build/config work.
The starter image is free and open source (it's just the Tela hub in a container). It feeds the funnel: users who start with the image may later register with Awan Saya for dashboard visibility, and some will eventually move to hosted hubs when they'd rather stop maintaining infrastructure.
Suggested tiers
Free - “Personal”
Target: home-labbers, hobbyists, individual developers, students.
- 3 registered hubs (self-hosted)
- 1 hosted hub — up to 3 machines, 2 concurrent sessions
- Relay endpoint for 1 self-hosted hub (no port forwarding or Cloudflare needed)
- Unlimited machines per self-hosted hub (that's the hub's problem, not Awan Saya's)
- Hub directory and name resolution
- Dashboard with live machine/service status
- 7-day connection history retention
- 1 portal user (the operator)
- Community support (GitHub issues)
Rationale: 3 self-hosted hubs covers the typical personal setup (home, VPS, work lab). The single hosted hub lets someone with no server at all get started — install telad on a home machine, point it at the hosted hub, and access it from anywhere. The relay slot lets users who do run their own hub skip the Cloudflare Tunnel / DDNS / port-forwarding dance entirely. These are not loss leaders; both cost less than a dollar a month in shared infrastructure at low utilization. The 7-day history is enough to debug recent issues without creating unbounded storage costs.
Pro - “Team”
Target: small teams, DevOps groups, education labs, small MSPs, freelancers.
- 15 registered hubs (self-hosted)
- 3 hosted hubs — up to 10 machines each, 10 concurrent sessions each
- Relay endpoints for all self-hosted hubs
- 5 portal users with role-based dashboard access
- 90-day connection history
- Hub health monitoring with email/webhook alerts
- Custom portal subdomain (e.g.,
acme.awansaya.net) - Usage analytics (connections per hub/machine, peak concurrent sessions)
- Priority support (email, faster response)
Rationale: This is where the hosted-hub value really lands. A freelancer or small shop that doesn't want to maintain a VPS gets three managed hubs with enough capacity for a real workload. An MSP can host a hub per client without provisioning cloud VMs. The relay-for-all-hubs unlock is also significant: teams running their own hubs in office environments immediately get stable public reachability without any networking setup. The 10-machine / 10-session limits per hosted hub are generous enough for most small-team use cases. The education-labs and distributed-teams use cases from the docs land squarely here.
Business - “Organization”
Target: larger organizations, MSPs with multiple clients, enterprises with compliance needs.
- Unlimited registered hubs (self-hosted)
- 10 hosted hubs (additional available on request or as add-on packs)
- Unlimited machines and concurrent sessions per hosted hub
- Relay endpoints for all self-hosted hubs
- Unlimited portal users
- SSO integration (SAML/OIDC) for portal access
- Audit log (who connected to what, when, from where)
- 1-year history retention
- API access for automation and integration
- Hub grouping/tagging (by client, region, environment)
- Custom domain (bring your own)
- SLA with guaranteed uptime for hosted hubs and relay
- Dedicated support channel
Rationale: The MSP use case (documented in howto/msp-it-support.md) is naturally multi-tenant: one MSP manages hubs for many clients and needs audit trails. With hosted hubs, the MSP doesn't need to provision or maintain hub infrastructure at all — they focus on managing their clients' machines. Enterprises need SSO and audit for compliance. The unlimited model works because Awan Saya's per-hub cost is low and this tier's price can absorb it. The unlimited-machines-per-hosted-hub at this tier acknowledges that Business customers may have large fleets behind a single hub.
Hosted hub resource model
Hosted hubs (Model C) and relay endpoints (Model B) introduce real infrastructure costs. The limits below reflect actual resource consumption, not artificial scarcity.
| Resource | Free | Pro | Business |
|---|---|---|---|
| Hosted hubs | 1 | 3 | 10 (expandable) |
| Machines per hosted hub | 3 | 10 | Unlimited |
| Concurrent sessions per hosted hub | 2 | 10 | Unlimited |
| Relay endpoints (Model B) | 1 hub | All hubs | All hubs |
| Hub bandwidth | Shared / best-effort | Shared / priority | Dedicated / SLA-backed |
What these limits mean in practice:
- Machines per hub is the number of
teladagents that can register simultaneously on a hosted hub. This is a direct memory and connection cost. - Concurrent sessions is the number of active tunnels at once. Each session is a WebSocket connection pair plus optional UDP relay state.
- Relay endpoints let a self-hosted hub accept connections through Awan Saya's network without port forwarding. Cost is WebSocket frame forwarding — lighter than a hosted hub since no session brokering or auth processing happens on the Awan Saya side.
Self-hosted hubs remain unlimited. The resource limits above apply only to hubs that Awan Saya hosts or relays. If you run your own hub, Awan Saya doesn't limit machines, sessions, or bandwidth because it doesn't provide those resources.
Things I'd avoid
Don't limit machines or sessions on self-hosted hubs. Awan Saya doesn't host the machines; the user's own hub does. Capping machines creates artificial friction around something that costs Awan Saya nothing. It would also feel punitive to someone running telad on 20 IoT devices through a single hub.
Don't limit concurrent sessions or bandwidth on self-hosted hubs. Same reasoning: tunnel traffic never touches Awan Saya unless the user opts into relay or hosting. Limiting it would be dishonest since the portal isn't providing that resource.
Don't gate connection profiles behind a paid tier. Profiles are a tela feature (client-side YAML), not an Awan Saya feature. They work without any portal at all. Trying to lock them would require artificial hobbling of the open-source client, which undermines trust.
Don't make hosted hubs enterprise-only. The whole point of hosted hubs is to remove the self-hosting barrier. If only large organizations can afford them, individuals and small teams — the people who benefit most from not needing infrastructure — are left out. A constrained free hosted hub costs very little to operate and is the most effective conversion funnel into paid tiers.
Don't gate the starter image behind anything. The image is just the open-source hub in a container. Charging for it or requiring registration to pull it would be anti-pattern for a FOSS project. The image feeds the funnel; don't put a gate on the top of the funnel.
Where the real upsell lives
The jump from Free to Pro has two triggers:
- Team access + alerting. The moment a second person needs to see the dashboard or someone wants “tell me when my hub goes down.”
- Hosted hub capacity. When the free hosted hub's 3-machine / 2-session limit isn't enough, or a user needs more than one hosted hub. This is a natural trigger because the user is already running on Awan Saya infrastructure and the upgrade is seamless — same hub URL, more capacity.
The jump from Pro to Business has two triggers:
- SSO + audit. When an organization's security team asks “who connected to the production database last Tuesday.” MSPs hit this naturally because their clients demand audit trails.
- Hosted hub scale + SLA. When 3 hosted hubs or 10 machines per hub isn't enough, or when the team needs an SLA on hosted infrastructure.
Infrastructure cost analysis
Resource profile of a hosted hub
A telahubd process is a single Go binary relaying WireGuard ciphertext over WebSocket. Resource consumption is modest:
| Resource | Free hub (3 machines, 2 sessions) | Pro hub (10 machines, 10 sessions) | Business hub (heavy use) |
|---|---|---|---|
| RAM | 30-50 MB | 80-150 MB | 200 MB - 1 GB |
| CPU | Negligible (idle most of the time) | Light (frame forwarding) | Moderate under load |
| Bandwidth | Protocol-dependent (see below) | Protocol-dependent | Protocol-dependent |
| Storage | < 5 MB (config + history) | < 10 MB | < 50 MB |
Bandwidth varies enormously by session type:
| Session type | Typical throughput | Per-hour data |
|---|---|---|
| SSH (interactive) | 10-50 KB/s | 36-180 MB |
| SSH (file transfer) | 1-10 MB/s | 3.6-36 GB |
| Database queries | Bursty, generally low | < 100 MB |
| RDP (desktop) | 1-5 Mbps | 0.5-2.3 GB |
| HTTP/API traffic | Variable | Variable |
Tela's transport upgrade cascade works in the hosted hub's favor. When sessions upgrade to UDP relay or direct P2P, the hub forwards nothing for that session after the initial handshake. Only WebSocket-only sessions (behind corporate firewalls that block UDP) generate sustained relay bandwidth. In practice, a significant fraction of sessions upgrade off the hub.
Hub density per server
Multiple hosted hubs share a single server. The constraint is RAM, not CPU.
| Server size | Free hubs per server | Pro hubs per server | Business hubs per server |
|---|---|---|---|
| 4 GB RAM | ~60-80 | ~25-40 | 4-15 |
| 8 GB RAM | ~120-160 | ~50-80 | 8-30 |
| 16 GB RAM | ~250-300 | ~100-160 | 15-60 |
Hosting provider comparison
Monthly cost per server (as of early 2025):
| Provider | 4 GB RAM | 8 GB RAM | 16 GB RAM | Bandwidth included | Overage |
|---|---|---|---|---|---|
| Hetzner Cloud (EU) | ~$5 | ~$9 | ~$17 | 20 TB | $1.19/TB |
| Hetzner ARM (EU) | ~$4 | ~$7 | ~$14 | 20 TB | $1.19/TB |
| Vultr | $12 | $24 | $48 | 3-4 TB | $10/TB |
| DigitalOcean | $12 | $24 | $48 | 4-5 TB | $10/TB |
| AWS Lightsail | $12 | $24 | $48 | 3-5 TB | $90/TB |
| AWS EC2 (t4g) | ~$12 | ~$24 | ~$48 | 100 GB free | $90/TB |
Recommendation: Start with Hetzner. Best value for this workload, and 20 TB included bandwidth makes bandwidth effectively free until significant scale. Move to AWS later only if specific regions or compliance certifications are needed. Avoid AWS early — the $90/TB bandwidth overage can surprise you.
Per-hub infrastructure cost
Using Hetzner (best value):
| Tier | Hubs per server | Server cost | Per-hub cost |
|---|---|---|---|
| Free (30-50 MB each) | ~70 on a $5/mo server | $5/mo | ~$0.07/mo |
| Pro (80-150 MB each) | ~30 on a $5/mo server | $5/mo | ~$0.17/mo |
| Business (variable) | ~8 on a $5/mo server | $5/mo | ~$0.63/mo |
Using DigitalOcean (US-based, familiar to many users):
| Tier | Hubs per server | Server cost | Per-hub cost |
|---|---|---|---|
| Free | ~70 on a $12/mo server | $12/mo | ~$0.17/mo |
| Pro | ~30 on a $12/mo server | $12/mo | ~$0.40/mo |
| Business | ~8 on a $12/mo server | $12/mo | ~$1.50/mo |
Relay endpoints (Model B) are even cheaper — just WebSocket frame forwarding with no session brokering. Estimate ~$0.02-0.05/mo per relay slot.
Pricing
Comparable products
| Product | Free | ~Pro equivalent | ~Business equivalent |
|---|---|---|---|
| Tailscale | $0 (3 users) | $6/user/mo | $18/user/mo |
| ngrok | $0 (1 endpoint) | $8/mo | $20/mo |
| Teleport | $0 (limited) | $15/user/mo | Custom |
| Cloudflare Zero Trust | $0 (basic) | $5/user/mo | $7/user/mo |
Awan Saya is more niche than these (which is fine — niche means less competition and clearer value prop). Pricing should reflect that the product is early-stage and building trust, while still capturing real value.
Suggested prices and margins
| Tier | Price | Hosted hub cost | Portal/infra overhead | Gross margin |
|---|---|---|---|---|
| Free | $0/mo | ~$0.07-0.17 per active user | ~$0.05 | -$0.12 to -$0.22 (loss leader) |
| Pro | $12/mo | ~$0.50-1.20 (3 hubs) | ~$0.20 | ~88-94% |
| Business | $59/mo | ~$6-15 (10 hubs, heavier use) | ~$1.00 | ~73-88% |
Why $12/mo for Pro: Below the “I need to ask my manager” threshold. A freelancer pays this without thinking. A small team splits it trivially. It undercuts ngrok ($8/mo but fewer features at that tier), is comparable to Tailscale per-user pricing for a 2-person team, and the margin is excellent.
Why $59/mo for Business: SSO + audit + SLA justify a clear step up. $59 is still cheap compared to enterprise tools ($15-18/user/mo at Tailscale/Teleport scales to hundreds fast). An MSP with 5 clients paying $500+/mo each will not blink at $59.
Why not charge for Free hosted hubs separately: The conversion math works better as a funnel. A free hosted hub costs ~$0.07-0.17/mo. Even at a 2% conversion rate, each paying Pro user at $12/mo funds 70-170 free users. The math is overwhelmingly positive.
Revenue projections
Speculative, but based on typical freemium SaaS conversion rates (2-5% free-to-paid). All figures in USD.
Conservative (solo founder, organic growth, no marketing spend)
| Free users | Pro ($12/mo) | Business ($59/mo) | MRR | ARR | |
|---|---|---|---|---|---|
| Month 6 | 100 | 3 | 0 | $36 | $432 |
| Year 1 | 500 | 15 | 2 | $298 | $3,576 |
| Year 2 | 2,000 | 60 | 8 | $1,192 | $14,304 |
| Year 3 | 5,000 | 150 | 25 | $3,275 | $39,300 |
Infrastructure cost at Year 3: ~$100-200/mo. Healthy margins from the start.
Moderate (active content marketing, conference talks, good SEO)
| Free users | Pro ($12/mo) | Business ($59/mo) | MRR | ARR | |
|---|---|---|---|---|---|
| Year 1 | 2,000 | 50 | 5 | $895 | $10,740 |
| Year 2 | 8,000 | 250 | 30 | $4,770 | $57,240 |
| Year 3 | 25,000 | 800 | 100 | $15,500 | $186,000 |
Infrastructure at Year 3: ~$500-1,000/mo. Still very healthy margins.
Optimistic (product-market fit, word of mouth, viral exposure)
| Free users | Pro ($12/mo) | Business ($59/mo) | MRR | ARR | |
|---|---|---|---|---|---|
| Year 1 | 5,000 | 150 | 15 | $2,685 | $32,220 |
| Year 2 | 30,000 | 1,200 | 100 | $20,300 | $243,600 |
| Year 3 | 100,000 | 4,000 | 400 | $71,600 | $859,200 |
Infrastructure at Year 3: ~$3,000-5,000/mo. Hiring becomes necessary.
Key observations
Infrastructure costs are very low. A hosted telahubd is a tiny Go process. At Hetzner prices, a Free-tier hosted hub costs about $0.07/mo. This means hosted hubs are viable at every tier, not just enterprise.
Bandwidth is the variable to watch, but transport upgrades help. When sessions upgrade to UDP relay or direct P2P, hub bandwidth drops to near zero. The worst case (all users on WebSocket relay doing RDP) is unlikely in practice.
Pro does the heavy lifting. In all scenarios, Pro revenue dominates early because it has the highest volume-to-price ratio. Business catches up as enterprise features (SSO, audit) land.
Free-tier hosted hubs are cheap insurance. At $0.07-0.17/user/mo, the free hosted hub is the most cost-effective acquisition channel available. It eliminates the biggest barrier to adoption (needing infrastructure) and funnels users toward paid tiers as they grow.
Not all free users cost money. Many free users will only use the portal for self-hosted hubs (near-zero cost to serve). Estimate ~30% of free users will actively use their hosted hub, which keeps the real free-tier infrastructure cost well below the headline number.
Hosted hub abuse prevention
Hosted hubs run on Awan Saya's infrastructure. Unlike self-hosted hubs (which are the user's problem), hosted hubs create direct risk: a compromised or malicious hub could generate massive bandwidth bills, get Awan Saya's IP ranges blacklisted, or turn the platform into a relay for botnet traffic. The controls below protect against these outcomes without degrading legitimate use.
Hard infrastructure limits (container level)
Every hosted hub runs in its own container with enforced resource ceilings. These are not application-level limits — they're enforced by the container runtime (Docker/Podman cgroup settings) or the orchestrator (Kubernetes resource limits).
| Resource | Free hub | Pro hub | Business hub |
|---|---|---|---|
| Bandwidth cap | 10 GB/month | 100 GB/month | 1 TB/month (SLA-backed) |
| Memory | 64 MB | 256 MB | 1 GB |
| CPU | 0.1 core | 0.25 core | 1 core |
| Max concurrent WebSocket connections | 10 | 50 | 500 |
| Max connection rate | 5/sec | 20/sec | 100/sec |
When a hub hits its bandwidth cap, relay traffic is throttled (not killed) — connections stay up but at reduced throughput. The hub owner gets an email at 80% and 100%. Pro and Business users can purchase additional bandwidth as an add-on.
Egress firewall
Hosted hub containers should have restricted outbound access. A telahubd process needs to:
- Accept inbound WebSocket connections from
teladagents andtelaclients - Relay WireGuard ciphertext between them
- Optionally connect outbound to an Awan Saya portal URL for registration
- Optionally relay UDP for transport upgrades
It does not need to make arbitrary outbound HTTP/TCP connections. An egress firewall (iptables rules on the host, or Kubernetes NetworkPolicy) should restrict each hub container to:
- Outbound to Awan Saya portal endpoints (HTTPS)
- Outbound DNS
- Inbound on 8080/tcp and 41820/udp
- Nothing else
This prevents a compromised hub from being used as a forward proxy, port scanner, or C2 callback channel.
Per-hub monitoring
Each hosted hub should emit or expose metrics that the Awan Saya monitoring stack collects:
| Metric | What it catches |
|---|---|
| Bytes transferred (in/out, per hour) | Bandwidth abuse, unexpected bulk transfers |
| Connection count (current + rate) | DDoS amplification, connection flooding |
| Unique source IPs (per hour) | Botnet-like fan-in patterns |
| Session duration distribution | Abnormally short sessions (scanning), abnormally long (persistent tunnel abuse) |
| Idle time | Hubs that are registered but never used (resource squatting) |
| Failed auth rate | Brute-force token guessing |
Alerts fire when metrics exceed thresholds (configurable per tier). The initial thresholds should be generous and tightened based on observed normal usage patterns.
Aggregate host monitoring
Beyond per-hub metrics, monitor the host machines themselves:
- Total outbound bandwidth per host — catches the case where many hubs on the same host collectively spike
- Host CPU and memory — ensures hub density assumptions hold
- IP reputation — periodic checks against blocklists (Spamhaus, AbuseIPDB) for the host's public IPs
If a host's IP appears on a blocklist, that's an immediate investigation trigger.
Account-level controls
| Control | Purpose |
|---|---|
| Email verification (all tiers) | Raises the cost of creating throwaway accounts |
| Credit card on file (Pro and Business) | Strong identity signal; enables chargebacks for abuse |
| One free hosted hub per verified email | Prevents bulk free-hub farming |
| Acceptable Use Policy | Legal basis for suspension; explicitly prohibits relay of attack traffic, spam, illegal content |
| Rate limit on hub creation | Prevents scripted mass hub provisioning |
Reactive tooling
When abuse is detected or reported:
- Hub suspension — Awan Saya can pause a hosted hub (stop the container) without deleting it. The owner sees a “suspended” status in the dashboard and gets an email explaining why. This is reversible.
- Hub termination — for confirmed abuse, delete the hub and its data. Irreversible.
- Account suspension — for repeat offenders, suspend the entire account (all hosted hubs paused).
- Abuse contact — publish
abuse@awansaya.netand respond to reports within 24 hours. This is important for maintaining IP reputation with hosting providers. - Hosting provider communication — if Hetzner/DO/etc. sends an abuse notice, the monitoring data should make it straightforward to identify and suspend the offending hub quickly.
Architecture-level containment
The hosted hub architecture should assume that any individual hub might be compromised:
- Network isolation: each hub container gets its own network namespace. Hubs cannot communicate with each other or with the host's internal services.
- No shared secrets: each hub has its own owner token. Compromising one hub's token gives no access to others.
- No host access: hub containers run as non-root with a read-only filesystem (except the data volume). No capability escalation.
- Bandwidth accounting at the reverse proxy: the reverse proxy (Caddy, nginx, or cloud load balancer) in front of hosted hubs logs per-hub traffic independently of the hub process itself. Even if the hub process is compromised and lies about its metrics, the proxy's numbers are authoritative.
Implementation priority
Before launch:
- Container resource limits (memory, CPU) — trivial to set in docker-compose or K8s manifests
- Egress firewall rules — iptables or NetworkPolicy, one-time setup
- Bandwidth metering at the reverse proxy — nginx
limit_rateor Caddy equivalent - Email verification for account creation
- AUP published on the site
Shortly after launch:
- Per-hub metrics collection and dashboard (Prometheus + Grafana or equivalent)
- Automated alerts for bandwidth and connection-rate thresholds
- Hub suspension tooling (admin API endpoint)
- IP reputation monitoring (cron job checking blocklists)
- Abuse contact email and response process
One more thought
Consider an open-core angle for Awan Saya itself: release a self-hostable portal (community edition) that covers the Free tier's portal feature set (minus hosted hubs and relay — those are tied to Awan Saya's infrastructure by definition), and offer Awan Saya hosted service as the convenient alternative with the higher tiers. This parallels GitLab CE/EE, Grafana OSS/Cloud, etc. It protects against the “what if Awan Saya goes away” concern and builds trust in the ecosystem, while the hosted service wins on convenience and the paid features (SSO, audit, alerting, hosted hubs) that are genuinely harder to self-operate. Hosted hubs and relay are natural platform-only features that can't be replicated by self-hosting the portal, giving the managed service a clear differentiator beyond just convenience.