Add a "Tunnel Locally" Tool - Bring Local Server to the Internet

Add a "Tunnel Locally" Tool - Bring Local Server to the Internet

Daily short news for you
  • For a long time, I have been thinking about how to increase brand presence, as well as users for the blog. After much contemplation, it seems the only way is to share on social media or hope they seek it out, until...

    Wearing this shirt means no more worries about traffic jams, the more crowded it gets, the more fun it is because hundreds of eyes are watching 🤓

    (It really works, you know 🤭)

    » Read more
  • A cycle of developing many projects is quite interesting. Summarized in 3 steps: See something complex -> Simplify it -> Add features until it becomes complex again... -> Back to a new loop.

    Why is that? Let me give you 2 examples to illustrate.

    Markdown was created with the aim of producing a plain text format that is "easy to write, easy to read, and easy to convert into something like HTML." At that time, no one had the patience to sit and write while also adding formatting for how the text displayed on the web. Yet now, people are "stuffing" or creating variations based on markdown to add so many new formats that… they can’t even remember all the syntax.

    React is also an example. Since the time of PHP, there has been a desire to create something that clearly separates the user interface from the core logic processing of applications into two distinct parts for better readability and writing. The result is that UI/UX libraries have developed very robustly, providing excellent user interaction, while the application logic resides on a separate server. The duo of Front-end and Back-end emerged from this, with the indispensable REST API waiter. Yet now, React doesn’t look much different from PHP, leading to Vue, Svelte... all converging back to a single point.

    However, the loop is not bad; on the contrary, this loop is more about evolution than "regression." Sometimes, it creates something good from something old, and people rely on that goodness to continue the loop. In other words, it’s about distilling the essence little by little 😁

    » Read more
  • Alongside the official projects, I occasionally see "side" projects aimed at optimizing or improving the language in some aspects. For example, nature-lang/nature is a project focused on enhancing Go, introducing some changes to make using Go more user-friendly.

    Looking back, it resembles JavaScript quite a bit 😆

    » Read more

Issue

Tunnel Locally is a concept that refers to the act of publishing a local server to the "common network" with the Internet. As a result, we don't need to deploy the server officially while still allowing others to view it.

As everyone knows, when starting a local server, for example node index.js to run a RESTful API, it can usually only be accessed on the current computer. At most, it allows additional machines on the same LAN to connect, provided they must connect to the same network.

During application development, there are many times when we need to use tunnel locally, such as allowing others to preview a "demo" of a website or test an API when they are very far away. Or more commonly, needing an https address pointing to the computer to check and develop features for integrating webhooks with someone else.

In reality, there are many ways to publish a local server to the Internet, and many tools and services not only help us do that but also provide addresses with https support. Just go online, type the keyword "Tunnel Locally," and there are dozens of results for you to choose from.

Previously, I often used two tools: ngrok and localhost.run. While ngrok requires installation on the machine, localhost.run is very simple to start; just type a single command, and the server is immediately mapped to the Internet.

In return, ngrok operates more stably than the other. Generally, if you want something quick and simple, use localhost.run; if you want stability, use ngrok.

Limitations

Typically, the critical point of services like this is the ability to maintain a domain name, also known as the option to choose a domain name. The domain name is randomly assigned each time you start, and it can even change continuously after a certain period or when the connection drops. In summary, changing domain names causes quite a bit of hassle as you have to spend time updating the new address.

Recognizing this, they---the service providers---offer options to use a fixed domain name, which can either be your own or assigned to a fixed subdomain. In return, you need to pay to use it or it could be free until a few thousand calls afterward it gets locked.

Recently, as my "technology stack" is gradually shifting to Cloudflare, many interesting things have been discovered. One of them is the tool cloudflared from Cloudflare. In simple terms, it also allows the use of tunnel locally, but completely for free.

cloudflared

Installing cloudflared is somewhat complex, but in return, it allows you to manage centralized services and utilize the domains managed by Cloudflare to map the local server to those addresses.

See the detailed setup guide at Set up a tunnel locally, but in summary, the steps are as follows.

Step 1: Install the CLI. The example below uses the brew command in MacOS.

$ brew install cloudflared

Step 2: Log in and authenticate using your Cloudflare account.

$ cloudflared tunnel login

Step 3: Create a tunnel ready for publishing:

$ cloudflared tunnel create <NAME>

This command creates a JSON file containing the configuration; use the cloudflared tunnel list command to view the list of all created tunnels.

Step 4: Create the cloudflared configuration file

In the .cloudflared directory (see the path at Default cloudflared directory), create a config.yml file containing the following content.

url: http://localhost:8000
tunnel: <Tunnel-UUID>
credentials-file: path/to/.cloudflared/<Tunnel-UUID>.json

Where url is the local address to be published, tunnel is the UUID created from step 3, and credentials-file is the path to the JSON file of the UUID.

Step 5: Create a subdomain to connect to the local address

$ cloudflared tunnel route dns <UUID or NAME> <subdomain>

Step 6: Run

$ cloudflared tunnel run <UUID or NAME>

You will see a screen similar to

Testing tunnel locally

Try accessing the subdomain, and you will receive results from the local server. Readers can also configure directly in the config.yml file to expand additional features.

Open the config.yml file and edit it:

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: path/to/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  - hostname: local80.mydomain.com
    service: http://localhost:80
  - hostname: local8080.mydomain.com
    service: http://localhost:8080
  - service: http_status:404

When accessing local80 or local8080, you will be directed to the corresponding services. Note that you must create the subdomain record before using it (see step 5).

Additionally, there are still many things that can be done with Cloudflare's Tunnel Locally; readers can refer to Cloudflare Tunnel.

Premium
Hello

The secret stack of Blog

As a developer, are you curious about the technology secrets or the technical debts of this blog? All secrets will be revealed in the article below. What are you waiting for, click now!

As a developer, are you curious about the technology secrets or the technical debts of this blog? All secrets will be revealed in the article below. What are you waiting for, click now!

View all

Subscribe to receive new article notifications

or
* The summary newsletter is sent every 1-2 weeks, cancel anytime.

Comments (1)

Leave a comment...
Avatar
Ẩn danh11 months ago

hay bạn,rất bổ ích

Reply