How to Host Localhost Globally Using Microsoft Dev Tunnels (Complete Guide)

These are examples, not fixed requirements. Always check the actual URL printed by your development server.

For this tutorial, we will use port 3000.

Step 4: Host Localhost Globally

Open a second terminal while keeping your application running.

Execute:

devtunnel host -p 3000

This command asks Dev Tunnels to create a temporary tunnel for the local service listening on port 3000.

If everything works, the CLI prints a tunnel ID and one or more URLs.

An illustrative URL might look like this:

https://example-3000.devtunnels.ms/

Your actual tunnel ID and URL will be different.

Open the displayed URL in your browser to test the connection.

What if your application uses another port?

Replace 3000 with the port your application actually uses.

For a Vite application running on port 5173:

devtunnel host -p 5173

For a Java Spring Boot API running on port 8080:

devtunnel host -p 8080

For an application using ports 3000 and 8080 simultaneously:

devtunnel host -p 3000 8080

The corresponding local services must already be running, and each port should use the appropriate protocol.

Step 5: Understand the devtunnels.ms URL

One of the most useful parts of Dev Tunnels is the URL generated for your local application.

A URL may resemble:

https://<tunnel-id>-<port>.devtunnels.ms/

The exact hostname format can vary depending on the tunnel configuration and service region.

The URL provides a remote entry point for the configured local port. It does not mean your application has been permanently deployed.

If the tunnel requires authentication, a visitor may be redirected to sign in before reaching your application.

If the visitor is not authorized, they will not be able to access the protected tunnel.

Can anyone open a Dev Tunnels URL?

Not necessarily.

By default, tunnels are private and accessible to the tunnel owner. You can grant access through supported authentication and access-control options.

If you explicitly allow anonymous access, visitors will not need to authenticate with an account to reach the tunnel. However, anyone who obtains the URL may be able to access the exposed service.

For that reason, choose the access configuration based on the purpose of your project.

Step 6: Share Your Localhost With Anyone

Suppose you want a client to review your website without deploying it to a production server.

You can follow this process:

1. Start your local application.
2. Run devtunnel host -p 3000.
3. Copy the URL printed by the CLI.
4. Configure the tunnel’s access permissions for the intended audience.
5. Share the URL with your client.
6. Keep your application and tunnel-hosting process running while the client tests it.

If the client needs anonymous browser access, configure that permission deliberately.

For a temporary demonstration where the application contains no sensitive data, you can run:

devtunnel host -p 3000 --allow-anonymous

This example creates a temporary tunnel with anonymous access enabled. It should only be used when you understand the exposure and the application is safe to make accessible without authentication.

Security reminder: Do not expose an application containing customer information, private APIs, administrative functions, or development credentials through anonymous access.

Step 7: Create a Reusable Dev Tunnel

The previous examples use temporary tunnels. If you repeatedly need to share the same development environment, you can create a named tunnel and reuse it.

Create a tunnel:

devtunnel create my-local-app

Add the port:

devtunnel port create my-local-app -p 3000 --protocol http

Host the existing tunnel:

devtunnel host my-local-app

Use the commands supported by your installed CLI version, and check the output for the tunnel’s actual URL.

A reusable tunnel can be more convenient than creating a new tunnel for every session. However, you should not assume that the URL will remain available indefinitely. Tunnel expiration, inactivity, and access settings still apply.

For additional commands, consult the official CLI reference:

https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/cli-commands

Step 8: Test Your Tunnel From Another Device

Once the tunnel is running, test it from a separate device or network.

For example:

• Open the generated URL on your mobile phone.
• Ask a teammate to test the application.
• Use an API client to send requests to an exposed development endpoint.
• Test a webhook integration that needs to reach your local service.

If the tunnel requires authentication, make sure the person testing it has the necessary permissions.

If the URL does not load, verify that the application is running, the correct port is exposed, and the tunnel-hosting process has not stopped.

Step 9: Use Dev Tunnels for APIs and Webhooks

Dev Tunnels is useful for more than frontend applications.

Imagine you are building a Java Spring Boot API:

@RestController
@RequestMapping("/api")
public class HelloController {

    @GetMapping("/hello")
    public String hello() {
        return "Hello from localhost!";
    }
}

If the application runs on port 8080, start the tunnel:

devtunnel host -p 8080

You can then use the generated HTTPS URL as the base address for remote testing.

For example, if the tunnel URL is https://example-8080.devtunnels.ms/, your endpoint would be:

https://example-8080.devtunnels.ms/api/hello

Replace the example hostname with the actual URL generated by your CLI.

This approach can also help test webhook callbacks from third-party services, provided their callback requirements are compatible with the tunnel and your application.

For API testing, remember that authentication, request validation, CORS, and webhook signature verification are still your application’s responsibility.

Step 10: Stop the Tunnel

When you finish testing, stop the hosting process using:

Ctrl + C

This terminates the current hosting session and its active tunnel connections.

For temporary tunnels, the tunnel created by the hosting command is deleted when the process exits. For a previously created tunnel, the tunnel resource may remain available for later use, subject to its configuration and expiration.

Stopping a tunnel is a simple way to prevent further access through that active hosting session.

Sharing localhost is convenient, but it also introduces security considerations.

Follow these precautions before sharing your URL:

1. Keep anonymous access disabled by default. Enable it only when public access is necessary.
2. Avoid exposing sensitive services. Do not publish development databases, admin dashboards, or internal management APIs.
3. Use test data. Avoid real customer records, production secrets, and confidential files.
4. Keep authentication enabled. Use the tunnel’s access controls and your application’s own authentication where appropriate.
5. Review your configuration. Make sure only the required ports are exposed.
6. Stop tunnels after testing. Do not leave unnecessary development services accessible.
7. Protect environment variables. Never share .env files, credentials, API keys, or private tokens.
8. Remember that HTTPS is not authorization. Encryption protects traffic in transit, but it does not make a publicly accessible application private.

Microsoft documents the service’s access-control and transport-security model here:

https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/security

# Common Dev Tunnels Problems and Solutions

1. The devtunnel command is not recognized

The CLI may not be installed correctly, or its executable directory may not be on your PATH.

Solution: Verify the installation, open a new terminal, and check devtunnel --version.

2. The tunnel URL does not open

Your local server may have stopped, or you may have exposed the wrong port.

Solution: Open the local application first, confirm the port, and restart the tunnel using that port.

3. The browser requests authentication

This is expected when the tunnel is private.

Solution: Sign in with an authorized account or configure access for the intended audience.

4. The application works locally but not through the tunnel

Your application may depend on a hostname, an allowed origin, cookies, or local network settings.

Solution: Review your development server’s host binding, CORS policy, authentication callbacks, and trusted-host configuration.

5. API requests fail through the tunnel

An API may reject requests because of authentication, incorrect paths, CORS, or application-specific restrictions.

Solution: Inspect the HTTP response and server logs, and verify the endpoint using the generated URL.

6. The URL stops working later

Temporary tunnels and reusable tunnels have different lifecycles. A stopped host process, expiration, or access-policy change can prevent access.

Solution: Restart the host process, check the tunnel’s configuration, and verify its current URL and expiration.

For detailed diagnostics, consult the official CLI documentation and use the supported verbose option where appropriate.

Dev Tunnels and traditional hosting solve different problems.

If you need to demonstrate a project, test a webhook, or share work in progress, Dev Tunnels can be convenient.

If you need a reliable public website for customers, use an appropriate production hosting environment instead.

# Frequently Asked Questions

1. How can I host localhost globally for free?

You can use Microsoft Dev Tunnels to expose a locally running service through an internet-accessible URL. Check Microsoft’s current terms and service availability for any applicable usage limits.

2. What is devtunnels.ms?

devtunnels.ms is a domain used by Microsoft's Dev Tunnels service to provide web-forwarding URLs for tunneled development services.

3. Do I need a domain name?

No. Dev Tunnels generates a URL for the configured tunnel, so you do not need to buy a separate domain just to share a development application.

4. Does my computer need to stay on?

Yes. Your local application and tunnel-hosting process need to remain available for the tunnel to forward requests to your computer.

5. Can I expose a React application?

Yes. Start your React development server, identify its local port, and host a tunnel for that port.

6. Can I expose a Java Spring Boot API?

Yes. If your Spring Boot application is listening on port 8080, you can run devtunnel host -p 8080 and use the generated URL to test its endpoints remotely.

7. Is anonymous access safe?

Anonymous access can be appropriate for a temporary demonstration of a non-sensitive application. It is risky for private applications, internal services, or systems containing sensitive data.

8. Can I use Dev Tunnels instead of production hosting?

It is best suited to development, debugging, and testing. Microsoft’s CLI documentation identifies the CLI as a preview feature and does not recommend it for production workloads. Review the current official documentation before relying on it for any business-critical use.

9. How do I stop sharing localhost?

Press Ctrl + C in the terminal running the tunnel host. Also review any reusable tunnel resources and access permissions you no longer need.

Final Thoughts

Microsoft Dev Tunnels offers developers a practical way to expose localhost to the internet without deploying an application to a public server.

Whether you work with React, Angular, Java Spring Boot, .NET, Python, or REST APIs, the workflow is similar: start your application, install and authenticate the CLI, expose the correct port, and share the generated URL with the intended audience.

The most important thing to remember is that sharing a local application is not the same as deploying a production website. Keep access controls enabled, avoid exposing sensitive services, and use production hosting when you need long-term public availability.

If you regularly demonstrate projects or test integrations, Dev Tunnels is a useful tool to add to your development workflow.

References & Official resources:

• Microsoft Dev Tunnels documentation
• Create and host a tunnel
• Dev Tunnels CLI reference
• Dev Tunnels security