One of the most powerful things about Akash Network is that it lets you deploy workloads across a global, decentralized marketplace of providers — each bringing their own hardware, location, and competitive pricing to the table. This diversity is a feature: it gives you geographic redundancy, cost flexibility, and true decentralization that no single cloud provider can match.

As you start building more sophisticated systems on Akash — distributed backends, AI inference pipelines, multi-region applications — a natural question comes up:

How do my workloads, running on different providers, talk to each other securely?

This is a real architectural challenge in any decentralized compute environment. Workloads on different providers exist in separate network namespaces. There are no guaranteed private subnets between providers. And for certain workloads like internal APIs, databases, model servers, job queues , you want communication to happen over a private channel, not the public internet

This guide walks through a clean, production-ready solution: building a private encrypted mesh network across your Akash deployments using Tailscale. It's lightweight, zero-configuration, and it runs entirely inside your containers.

What Is Tailscale?

Tailscale is a mesh VPN built on WireGuard — the same cryptographic protocol trusted by major cloud providers and security researchers worldwide. Every device that joins a Tailscale network (called a "Tailnet") gets a stable private IP address in the 100.x.x.x range, and encrypted peer-to-peer tunnels form automatically between nodes — even across NAT, firewalls, and different cloud environments.

For Akash deployments specifically, Tailscale's userspace networking mode (--tun=userspace-networking) is the key. It runs the WireGuard tunnel entirely in userspace, requiring no kernel-level TUN device — which means it works inside containers without any special privileges.

The result: your Akash workloads can form their own private network, no matter which providers they're running on.

How DERP Works

DERP servers are Tailscale's globally distributed relay network. When two nodes can't connect directly, their traffic is relayed through the nearest DERP server. Critically, the relay is end-to-end encrypted — DERP servers forward opaque WireGuard packets and have no ability to read the contents. The encryption keys never leave your nodes.

The result: your Akash workloads can form their own private encrypted network across providers, with traffic relayed through DERP when direct connections aren't available.

The Architecture

The pattern is straightforward. Each container:

1. Starts the Tailscale daemon in userspace mode

2. Joins your private Tailnet using an auth key

3. Runs your actual service bound to 127.0.0.1

Once all containers have joined the Tailnet, they can reach each other using their stable Tailscale IPs (100.x.x.x) — with end-to-end WireGuard encryption. Your internal service traffic stays inside the mesh and never needs to touch the public internet.

Get started

Generating a Tailscale Auth Key

1. Log in to the Tailscale Admin Console

2. Go to Settings → Keys

3. Click Generate auth key

4. Select Reusable so multiple deployments can join using the same key

5. Copy the key — it will look like tskey-auth-xxxx...

The SDL: Three Nodes, 3 Providers

Here's a set of three Akash SDLs that each spin up a container, join a private Tailnet, and run a small HTTP server accessible only within the mesh. You'd deploy each one separately to get workloads distributed across providers.

version: "2.0"
services:
  backend:
    image: alpine:latest
    expose:
      - port: 8000
        as: 8000
        to:
          - global: true
    env:
      - TS_AUTHKEY=tskey-auth-YOUR_KEY_HERE
      - TS_HOSTNAME=akash-server-1
    command:
      - /bin/sh
      - "-c"
    args:
      - |
        apk add tailscale python3

        # Start Tailscale in userspace mode (works in containers, no kernel TUN needed)
        tailscaled --tun=userspace-networking --socks5-server=localhost:1055 &
        sleep 5

        # Join the private Tailnet
        tailscale up \
          --authkey=$TS_AUTHKEY \
          --hostname=$TS_HOSTNAME \
          --reset \
          --accept-dns=false

        # Start the service — bound to loopback, reachable via Tailscale mesh
        echo "Hello from $TS_HOSTNAME" > index.html
        python3 -m http.server 8000 --bind 127.0.0.1
profiles:
  compute:
    backend:
      resources:
        cpu:
          units: 0.5
        memory:
          size: 512Mi
        storage:
          size: 512Mi
  placement:
    dcloud:
      pricing:
        backend:
          denom: ibc/170C677610AC31DF0904FFE09CD3B5C657492170E7E52372E48756B71E56F2F1
          amount: 1000
      signedBy:
        anyOf:
          - akash1365yvmc4s7awdyj3n2sav7xfx76adc6dnmlx63
        allOf: []
deployment:
  backend:
    dcloud:
      profile: backend
      count: 1

Node 2 — same SDL, change TS_HOSTNAME to akash-server-2
Node 3 — same SDL, change TS_HOSTNAME to akash-server-3

Once all three are deployed and running, open your Tailscale admin console. You'll see all three nodes listed with their 100.x.x.x private IPs, connected to each other.

With all nodes in the same Tailnet, inter-node communication is simple:

option : 1 through ip

curl -x socks5h://127.0.0.1:1055 http://100.90.158.125:8000

option :2 through host name

curl -x socks5h://127.0.0.1:1055 http://akash-server-1:8000

Because Akash containers sit behind NAT and don't own their network interfaces, Tailscale will typically route this traffic through the nearest DERP relay server rather than a direct P2P connection. The DERP server forwards opaque WireGuard ciphertext — it cannot read the contents. Your data stays end-to-end encrypted the whole way.

Real-World Use Cases

This pattern unlocks a range of distributed architectures that weren't straightforward to build on Akash before:

Distributed AI Inference
Run a coordinator node and multiple GPU worker nodes across different providers. The coordinator distributes inference jobs over the private mesh. Workers respond with results. No request payload is exposed to the public internet.

Internal APIs and Microservices
Build a microservices architecture where each service runs on the most cost-effective provider for its workload type. Service-to-service calls happen over the encrypted mesh. Only your public-facing gateway exposes a port to the world.

Private Databases
Run PostgreSQL or Redis bound to loopback. Only nodes in your Tailnet — authorized by ACL — can connect. Your database never appears on a port scan.

Multi-Region Job Queues
Distribute workers across geographic providers for latency-optimized job processing. Workers pull tasks from a coordinator over the mesh, results are returned the same way.

Staging Environments
Spin up an isolated Tailnet for a staging environment. Your staging services are completely unreachable from the outside world and from your production Tailnet — by design.

Conclusion:

This Tailscale pattern is specifically for the subset of workloads that have internal communication requirements — where services need to talk to each other and that communication is inherently private by design, the same way microservices in a Kubernetes cluster communicate over an internal network rather than the public internet. It doesn't change how you pay for compute, how providers are selected, or how the Akash marketplace works. Providers still get their bids, still run your containers, and still get paid.

Think of it as the Akash equivalent of Kubernetes' internal cluster networking — a pattern for building sophisticated distributed systems on top of the compute layer that Akash providers so reliably deliver.

In a traditional cloud, you rely on a Virtual Private Cloud (VPC) to isolate your databases. On Akash, your compute leases might be distributed across multiple independent providers globally. There is no native, cross-provider VPC.

To achieve enterprise-grade security and reliable connectivity for stateful databases on Akash, we must decouple the network from the physical infrastructure. This first part of the masterclass covers how to build a Zero-Trust, encrypted overlay network using Tailscale within your Akash SDL (Stack Definition Language).

1. The Architecture: Bridging Decentralized Providers

When deploying a distributed database, the nodes must communicate with each other seamlessly. If a Redis Master is leased from a provider in North America and a Replica is leased from a provider in Europe, they cannot safely communicate over the open internet without an encryption layer.

An overlay network acts as a dynamic, software-defined VPC that travels directly inside your Akash containers.

By installing a mesh VPN (like Tailscale) inside the deployment, we achieve three architectural goals crucial for the Akash ecosystem:

1. End-to-End Encryption: All database replication and gossip protocols are routed through WireGuard tunnels, completely hidden from the underlying provider.

2. Provider Agnosticism: Containers communicate using static 100.x.x.x mesh IPs. You can close a lease, spin up a new one on a completely different provider, and the mesh network will seamlessly re-route the traffic.

3. Zero-Trust Access: The database ports do not need to be exposed in the expose block of your Akash SDL, making them invisible to the public internet.

2. Securing the Database: Localhost Isolation on Public Compute

A common oversight when deploying Redis on public cloud infrastructure is leaving the default binding open. Configuring bind 0.0.0.0 tells the Redis process to listen for incoming connections on all available network interfaces.

From a Site Reliability Engineering perspective, the most secure database on decentralized compute is one that refuses to talk to the network at all.

We achieve absolute isolation by restricting Redis strictly to the container's loopback interface:

# /etc/redis/redis.conf
bind 127.0.0.1
requirepass <YOUR_STRONG_PASSWORD>  # Instead of using only requirepass, using ACL is a better security practice.

By binding to 127.0.0.1, Redis is now completely blind to the outside world and the underlying provider's network. It will only accept connections originating from inside its own container. We then use Tailscale to build a secure bridge into this isolated environment.

3. The Mesh Overlay: Userspace Networking on Akash

For security reasons, Akash providers drop elevated kernel privileges. This means containers do not have access to /dev/net/tun, which traditional VPNs require. To bypass this, we run the Tailscale daemon in userspace networking mode.

Once the node is authenticated to the mesh, we need a way to pass the encrypted mesh traffic to our isolated Redis instance. We use tailscale serve, a lightweight, built-in reverse proxy.

Here is the exact boot sequence to include in your deployment script:

# 1. Start Tailscale in Userspace Mode
tailscaled --tun=userspace-networking --socks5-server=localhost:1055 &

# 2. Authenticate the Node to the Mesh Network
tailscale up --authkey=\(TS_AUTHKEY --hostname=\)NODE_HOSTNAME --accept-dns=true

# 3. Route Mesh Traffic to the Local Database
tailscale serve --tcp=6379 127.0.0.1:6379

# 4. Start Redis in the background
proxychains4 -q redis-server /etc/redis/redis.conf &

Redis is safely restricted to 127.0.0.1, Tailscale is free to bind to the 6379 port on the mesh interface. Tailscale receives the encrypted WireGuard packets from other Akash deployments, decrypts them, and proxies them directly to Redis on localhost. Redis accepts the traffic because it appears to be entirely local.

1. Search for BotFather in the search bar.

2. Clicked on verified Botfather like the the below image

   

3. Open the chat and send any message, such as Hi.

4. click the command /newbot

5. Choose a name for your bot (for example, picoooo).

6. Choose the unique user name for your bot , it must end with “bot”
   ex: tetrisbot or tetris_bot

Once completed, you will receive a confirmation message along with your bot token. Copy and save this token securely.

Click the provided bot URL to start interacting with your new bot.

In this guide, I’ll walk you through how to deploy a Redis server on the Akash Network — a decentralized cloud computing marketplace. By the end of this tutorial, you will see how we achieved a running cost of just $1.98/month, compared to $20-$40/month on major platforms.

Let’s get started.

Why Akash?

Before we deploy, let’s look at the numbers.

• Traditional Cloud (e.g., Azure): A standard instance with ~1GB RAM often costs between $16 and $40 per month.

• Akash Network: For superior specs (1 VCPU, 1GI RAM), we secured a deal for $1.98 per month.

That is a massive difference for the exact same utility.

Step 1: Access the Console

First, navigate to the Akash Console → https://console.akash.network

• Click Sign In

Press enter or click to view image in full size

Get $100 free credits (for first-time users)

1. Click Sign Up using Gmail or email.

2. Verify your email and add your credit card to activate the credits.

3. Log in to your account.

4. Click Deploy.

5. Select Run Custom Container.

Step 2: Configure the Deployment (SDL)

Now need to define our Docker image and resource requirements. You can use the SDL Builder or edit the Yaml (SDL) directly.

The Configuration:

• Image: redis:8.4 (Or your preferred version)

• Port: 6379

• CPU: 1.0

• Memory: 1Gi

• Port 6379

• Ephimeral Storage(temporary) : 1Gi

• We also need to set a password for security so unauthorized users cannot access our cache. We do this by passing a command

- sh
- "-c"
- redis-server --appendonly yes --requirepass Test@123

Press enter or click to view image in full size

---
version: "2.0"
services:
  redis:
    image: redis:8.4
    expose:
      - port: 6379
        as: 6379
        to:
          - global: true
    command:
      - sh
      - "-c"
      - redis-server --appendonly yes --requirepass Test@123
profiles:
  compute:
    redis:
      resources:
        cpu:
          units: 1
        memory:
          size: 1Gi
        storage:
          - size: 1Gi
  placement:
    dcloud:
      pricing:
        redis:
          denom: ibc/170C677610AC31DF0904FFE09CD3B5C657492170E7E52372E48756B71E56F2F1
          amount: 100000
      signedBy:
        anyOf:
          - akash1365yvmc4s7awdyj3n2sav7xfx76adc6dnmlx63
        allOf: []
deployment:
  redis:
    dcloud:
      profile: redis
      count: 1

Here is the clean YAML (SDL) file . You can copy-paste this into the Yaml editor

(**Note: Change test@123 to a secure, strong password before deploying!)

Step 3: Deployment & Bidding

1. Deposit Funds: To create a deployment, you need to have at least $5 in an escrow account.

2. Click Create Deployment.

3. Choose a Provider: Akash is a cloud marketplace. Once you request resources, providers will bid on your workload.

• Wait a moment for bids to come in.

• In our example, we found a provider offering 100% uptime and a monthly cost of roughly $1.98

Press enter or click to view image in full size

4. Accept Bid: Select the provider and approve the transaction.

Step 4: Verification

Once the container status shows Active, verify that Redis is running correctly.

. Check Logs

Go to the Logs tab in the dashboard.
You should see Redis starting up and ready to accept connections.

. Install Redis CLI (if not installed)

On Ubuntu:

sudo apt install redis-tools

On macOS:

brew install redis

Get your Host and Port from the Leases section.

• Provider → Host

• External Port → Port

Once the container status shows Active, verify that Redis is running correctly.

Press enter or click to view image in full size

From your local machine terminal, test the Redis instance using redis-cli

redis-cli -h provider.ahn2-na.akash.pub -p 32030 -a Test@123

If successful, you should be connected.

Press enter or click to view image in full size

We successfully deployed a robust Redis instance with 1vCPUs and 1Gi RAM

Pricing compare (1 Gi redis cache per month)

Press enter or click to view image in full size

The setup took under five minutes, required no complicated contracts, and cut our infrastructure costs by more than 90%. If you’re trying to reduce your DevOps spend, migrating stateless workloads like Redis to Akash is an easy win.