The Problem with Multiple Tunnels

Modern web development typically involves running multiple services locally: a frontend on port 3000, an API backend on port 8080, maybe a database admin panel, documentation server, or debugging tools. When you need to share your work or test with external services, you face a choice: run multiple tunnels or find a better way.

With traditional tunnel providers like ngrok, exposing a frontend and backend means running two separate tunnels, each with its own URL:

• abc123.ngrok.io → your frontend on port 3000
• xyz789.ngrok.io → your API backend on port 8080

Now your frontend needs to know the backend URL. You update your environment variables, configure CORS, and hope nothing breaks when the tunnel restarts with a new URL. Testing webhooks? You need yet another tunnel. Sharing with a colleague? Send them multiple links and explain which is which.

This gets messy fast.

How ASD Solves This

ASD uses path-based routing powered by optimized Caddy configurations to serve multiple local services through a single tunnel. Instead of juggling multiple URLs, you get one:

• your-tunnel.tunnel.asd.host/ → your frontend on port 3000
• your-tunnel.tunnel.asd.host/api/ → your backend on port 8080
• your-tunnel.tunnel.asd.host/admin/ → your admin tools on port 5432

Your frontend makes API calls to /api/users — no environment variables needed, no CORS configuration, no URL management. It just works, locally and through the tunnel.

One Tunnel for Free Members

Path-based routing is how ASD provides real value even on the free tier. While other providers limit you to one tunnel per service, ASD's single tunnel can expose your entire development stack. Free members get access to:

• Unlimited local services through one tunnel
• Automatic path-based routing via asd.yaml configuration
• Optimized Caddy reverse proxy handling
• No artificial service limits

This means a free ASD account lets you expose a full-stack application — frontend, backend, database tools, and more — without paying for multiple tunnel slots.

Frontend + Backend: The Common Case

The most common scenario is a React/Vue/Svelte frontend calling a separate API backend. With ASD, you configure this in your asd.yaml:

# asd.yaml
services:
  frontend:
    port: 5173
    path: /

  api:
    port: 8080
    path: /api
    strip_prefix: true

The strip_prefix: true option is important — it removes /api from the request path before forwarding to your backend. So when your frontend calls /api/users, your backend receives /users, exactly as it expects.

Run asd start and both services are accessible through your tunnel. Your frontend's API calls work identically in local development and when accessed remotely.

Why This Matters

No More CORS Headaches

Since frontend and backend share the same origin (your-tunnel.tunnel.asd.host), there are no cross-origin issues. No CORS headers to configure, no preflight requests, no browser security warnings.

Consistent URLs Everywhere

Your frontend code uses relative paths like /api/users. This works in local development, through the tunnel, and in production. No environment-specific URL configuration needed.

Simplified Sharing

Share one URL with collaborators, clients, or webhook providers. They access your complete application stack through a single endpoint. No confusion about which URL does what.

Mobile App Development

Building a mobile app with a backend API? Configure your app with a single base URL. When testing, your tunnel serves both the API and any web-based admin tools you need.

Beyond Frontend and Backend

Path-based routing scales to more complex setups. A typical development environment might include:

# asd.yaml
services:
  # Main application
  app:
    port: 5173
    path: /

API backend
  api:
    port: 8080
    path: /api
    strip_prefix: true
Storybook for component development
  storybook:
    port: 6006
    path: /storybook
Swagger/OpenAPI documentation
  docs:
    port: 8081
    path: /docs
Database admin (Adminer, pgAdmin)
  db:
    port: 8082
    path: /db

One tunnel URL, five services. A colleague reviewing your work can see the app, test the API, browse the component library, read the API docs, and check the database — all from a single link.

How It Works Under the Hood

ASD generates optimized Caddy reverse proxy configurations based on your asd.yaml. When a request arrives at the tunnel:

1. Caddy matches the request path against your configured routes
2. The request is forwarded to the appropriate local port
3. If strip_prefix is enabled, the path prefix is removed
4. WebSocket connections are handled transparently
5. The response flows back through the tunnel

This happens with minimal latency overhead. Caddy is highly optimized for reverse proxy workloads, and ASD's generated configurations are tuned for development use cases.

Comparison: ASD vs Traditional Tunnels

Scenario	Traditional (ngrok)	ASD
Frontend + Backend	2 tunnels, 2 URLs	1 tunnel, 1 URL
CORS configuration	Required	Not needed
Frontend API URLs	Environment-dependent	Relative paths work everywhere
Adding a service	New tunnel needed	Add path to config
Free tier	Limited tunnels	Unlimited services per tunnel
Sharing with team	Multiple URLs to manage	Single URL for everything

Getting Started

If you're already using ASD, add a services section to your asd.yaml and run asd start. Your path-based routing is configured automatically.

New to ASD? Sign up for a free account and get path-based routing out of the box. No payment required to expose your full development stack through a single tunnel.

Conclusion

Path-based routing isn't just a convenience feature — it's a fundamentally better way to expose local development environments. By serving multiple services through one tunnel, ASD eliminates the URL juggling, CORS configuration, and environment variable management that plagues multi-tunnel setups.

Whether you're building a simple frontend/backend app or a complex microservices architecture, path-based routing keeps your development workflow clean and your sharing simple. One URL, all your services, zero hassle.