Local Hosting tools are useful to developers in many scenarios. There's many tools and providers to choose from and they are all built around the basic purpose of providing access to a locally running service that would otherwise be inaccessible to the Internet.

This solves a lot of problems in web development. The most basic is testing your code or sharing it with your team or a client. In other scenarios they make it possible to develop and test with an API that expect an HTTP/S callback to be publicly available. Examples of these APIs come from companies like Stripe, Intercom, Slack, GitHub, etc...

You may want to self-host applications or services that are part of your CI/CD workflow.

Let's quickly dive into how they work, how to roll your own, and some options for providers and tools that can save you time.

How They Work

Typically, they work by creating a reverse tunnel to a server from your workstation. The server uses HTTP virtual hosts and TLS-SNI parsing to route traffic to the reverse tunnel and eventually your system. Below is a diagram illustrating the basic architecture of most of these local hosting services and tools.

Roll Your Own

There's many ways to expose a local service. You can always setup your own server on a cloud provider and push code or fresh builds to that system.

Another option is to setup similar infrastructure to what local hosting services provide to you, a reverse tunnel that routes traffic to your workstation. There's a few ways to do this:

• Run a VM in the cloud, set it up as a VPN server, connect to it from your workstation, setup IP masquerading rules so that all HTTP/S or other traffic is NAT'd across the VPN connection to your server.

• Run a VM in the cloud, use SSH to create some reverse tunnels. Forward all HTTP/S and other traffic to your local server.

Implementing either isn't difficult if you have experience with VPNs or networking. Maybe you're juggling multiple projects, builds, or workstations, the effort can begin to accumulate and its not worth your time.

You'll also need to purchase a domain and setup DNS records. If your need is temporary or intermittent it may be too much effort.

Choosing a Provider

There's tools and services and that make this easy and automatic. I'll provide a list below, some opensource alternatives, and some honorable mentions at the end.

PageKite

PageKite has been around for while. It requires a Python interpreter and is easy to setup as long as Python is already installed. For most systems, this isn't an obstacle. There's paid tiers for more bandwidth, more simulatenous clients, custom subdomais from .pagekite.me and the ability to use create CNAME records using the assigned subdomains.

The PageKite client can serve to upstream servers or static content, but not both for the same site. If your upstream server has static content, it must serve it, or you need a web server like nginx in conjunction to help serve both.

With PageKite you can also IP whitelist and password protect subdomain and these features are available on their free tier.

Getting started with Pagekite is quick and easy:

$ curl -O https://pagekite.net/pk/pagekite.py
$ python pagekite.py 80 yourname.pagekite.me 

Registration and configuration is performed through a series of prompts in the client program. Email confirmation is required any real use of the service.

Ngrok

Ngrok is a another option that has been around for a few years and although it supports HTTP/S and TCP relaying, it was built to make developing and testing webhooks and API callbacks more efficiently. It does this by introducing a a web dashboard that enables you to inspect requests and replay them.

Ngrok comes with paid tiers as well that enable more custom domains, reserved TCP ports, IP whitelists, more bandwidth and more simultaneously running processes.

Getting started with Ngrok is straight-forward. You setup an account, download the right client for your platform and use the provided auth token to setup your client.

$ ./ngrok authtoken ABC123...
$ ./mgrok http 80

Packetriot

Let me first state that I'm the author of Packetriot.

The project has been around for almost a year and I've had a big interest in this space of tool development for some time. I started it to resolve gaps I experienced with existing tools. I wanted more integrated features and long-lived tunnels to enable more reliable self-hosting.

Packetriot provides the same features as tools mentioned earlier and fill the gaps they leave behind. Like PageKite it can serve static content, but it can also forward to upstream servers as well, on the same domain. Eliminating the need for setting up a separate web server like nginx or apache.

You probably own lots of domains (that you may never use...) You can setup CNAME and A records and they will work just fine.

Let's Encrypt is supported by the Packetriot client, along with automatic management of those certificates. The client will automatically renew certs before their expiration. No need to install certbot, setup a cron job to renew, or debug why the certbot integration isn't working.

Unlike Ngrok, the subdomain, e.g. abc-1234.pktriot.net, that is assigned to your tunnel is static. So for any given project you can create configurations with that hostname for testing and do not have to worry about editing it constantly.

All websites can be protected with a password. Paid plans include IP whitelists and blacklists, access logs and metrics per connection and grouped by destination website or TCP port.

There is even a upstream service health monitor that will email you when those services die. No need to integrate or pay for another monitoring tool.

Packaging and diverse platforms are well supported, along with a commitment to long-lived tunnels. Support for systemd services is included with each Debian and RPM package. All archives for Linux, Windows and Mac includes example configurations so that constant run-time can be setup. Containers are built for each new release as well.

You can serve any number of websites behind a Packetriot tunnel. The primary restriction is bandwidth. Paid plans provide you more tunnels, bandwidth, and more advanced features.

Getting started with Packetriot is easy. Once you create an account and confirm your email, find the right client and then setup traffic in one command.

$ pktriot http 8080

This will kick off several prompts to configure your client and then begin forwarding traffic to your local service.

You can perform more advance routing options with traffic rules that will be persistent. Below are some examples:

$ pktriot configure --login

# setup my custom domain, serve static and upstream, use automatic
# Let's Encrypt and redirect all HTTP requests to HTTPS.

$ pktriot route http add --domain example.com --webroot /path/to/static --http 8080 --letsencrypt --redirect

# transparently forward HTTP/S traffic to a host
$ pktriot route http add --domain example.com --http 80 --tls 443 --destination 192.168.0.10

# setup a password protected, static-file sharing site using 
$ Let's Encrypt and secure redirecting all requests.
$ pktriot route http add --domain example.com --webroot /path/to/static --password --letsencrypt --redirect


# allocate a TCP port that is assigned your tunnel until you delete
# the tunnel or release the port.
$ pktriot route tcp allocate
Port 22000 was allocated!

$ pktriot route tcp forward --port 22000 --destination 192.168.0.10 --dstport 22

Opensource Alternatives

There are a few opensource alternatives you can choose as well. sish uses SSH for setting up tunnels to a VM you create and setup.

FRP is a highly configurable and capable opensource alternative.

Honorable Mention

Serveo was an extremely popular local hosting tool. It was free, required no account creation and was cleverly built to leverage the existing ssh client to build it's tunnels. However, a system with no user creation or confirmation, was riped to be targeted by spammers and phishers, to obscure their systems and abuse users.

This led to constantly interruptions in service and its temporary shutdown. Who knows if it'll come back in its original form.

Conclusion

There are many local hosting tools to choose and although they try to serve the same core problem of making a local services available for sharing or testing, they all come with pros and cons.

If local hosting tools are new to you then I'm glad if I've been able to introduce them and provide a survey of what's available. Note, this is not a comprehensive list.

If you've been using these types of tools for some time, I hope there's tools or services I mentioned that are new to you. Please share your experience and let us know how you integrate these tools in your workflow.

Interested in more use-cases or how to configure these tools with your work environment? Let me know know in the comments.