DEV Community: Carson Yang

Headscale Deployment and Usage Guide: Mastering Tailscale's Self-Hosting Basics for Ultimate Control

Carson Yang — Mon, 24 Nov 2025 04:18:40 +0000

Headscale is an open-source server that works like Tailscale's control server. You can run it yourself instead of using Tailscale's hosted service. This gives you full control over your VPN network without device limits or subscription fees. Here's how to set it up and connect your devices.

What is Tailscale?

Tailscale is a VPN built on WireGuard. It works like other mesh VPN tools such as Netmaker. Tailscale runs WireGuard in user space, while Netmaker uses kernel-space WireGuard. This means Tailscale has slightly lower performance than kernel-space solutions. But it's still much faster than OpenVPN and easier to use.

Here's what makes Tailscale useful:

Simple setup:
- No firewall configuration needed.
- Easy network setup.
Security:
- Automatic key rotation.
- End-to-end encryption by default.
- Access logs you can review.
NAT traversal: Uses DERP (Detoured Encrypted Routing Protocol) over TCP when UDP doesn't work. This helps connections work even behind difficult firewalls.
Central control: Push access rules and settings to all devices from one place.
Easy authentication: Works with Google, Microsoft, GitHub, and other login providers.

Tailscale is basically WireGuard made easier to use.

Tailscale has a free tier that works well for personal use or small teams. You can use it free as long as you stay under the device limit (around 20 devices per account - check their website for current limits). The free tier has some limits on advanced features like subnet routing, but it covers most basic needs. Most Tailscale client code is open source under the BSD license (except Windows and macOS GUI apps). You can find the source code in their GitHub repository.

The free tier works for most people. If you need more features, they have paid plans.

But what if you want full control, unlimited devices, and no subscription fees? That's where Headscale comes in.

What is Headscale?

Tailscale's control server is proprietary and has limits for free users. That's fair since it's how they make money. But the open-source community built an alternative: Headscale. It's become the main open-source option for self-hosted Tailscale setups.

Juan Font at the European Space Agency created Headscale. It's written in Go and released under the BSD license. Headscale copies most of Tailscale's control server features. You can run the whole coordination server yourself. This gives you full control over your network traffic and removes device limits. If you want to run your own secure VPN without restrictions, Headscale is a good choice.

How to Deploy Headscale

Here are different ways to set up Headscale.

Quick Deploy with Sealos

If you want to get started fast, the Sealos App Store has one-click Headscale deployment. This is simple and needs almost no setup.

Click one of these to deploy Headscale:

SQLite version:
PostgreSQL version:

Click "Deploy on Sealos" to start. Sign in to your Sealos account, then click "Deploy Application." When it's done, click on the Headscale app's "Details" to see how to access it.

Your Headscale service will have a public domain that maps to internal port 8080.

Click on the public address to access your Headscale dashboard. This usually opens Headplane, a web interface for managing Headscale.

Deploy on a Linux Server

Setting up Headscale manually on Linux is pretty simple.

Tip: Headscale only needs internet access to work. But for best NAT traversal performance, use a cloud server with a public IP address. This avoids extra NAT layers and gives your Tailscale clients better connectivity.

First, download the latest Headscale binary from the GitHub releases page.

# Replace <HEADSCALE_VERSION> and <ARCH> with your version and architecture (e.g., v0.22.3, amd64)
$ wget --output-document=/usr/local/bin/headscale \
   https://github.com/juanfont/headscale/releases/download/v<HEADSCALE_VERSION>/headscale_<HEADSCALE_VERSION>_linux_<ARCH>

$ chmod +x /usr/local/bin/headscale

Create the config directory:

$ mkdir -p /etc/headscale

Create a directory for data storage (SQLite DB and SSL certificates):

$ mkdir -p /var/lib/headscale

Create an empty SQLite database file:

$ touch /var/lib/headscale/db.sqlite

Download the example config file:

$ wget https://github.com/juanfont/headscale/raw/main/config-example.yaml -O /etc/headscale/config.yaml

Now edit /etc/headscale/config.yaml:

Set server_url to your public IP or domain (e.g., http://<YOUR_PUBLIC_IP_OR_DOMAIN>:8080 or https://<YOUR_PUBLIC_IP_OR_DOMAIN>).
- Note: If using a domain in mainland China, make sure it has ICP filing. If not, just use your public IP address.
- For HTTPS, make sure your TLS certificates are set up correctly.
If you don't want MagicDNS initially, set dns_config.magic_dns to false.
Enable randomized client ports for better NAT traversal by setting randomize_client_port to true.

You can customize your private network IP ranges:

ip_prefixes:
  # - fd7a:115c:a1e0::/48  # IPv6 prefix for your network
  - 100.64.0.0/10        # Default address space used by Tailscale/Headscale

Create a SystemD service file so Headscale runs automatically:

# /etc/systemd/system/headscale.service
[Unit]
Description=Headscale Controller - Self-hosted Tailscale coordination server
After=syslog.target
After=network.target

[Service]
Type=simple
User=headscale
Group=headscale
ExecStart=/usr/local/bin/headscale serve
Restart=always
RestartSec=5

# Security settings
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/headscale /var/run/headscale
AmbientCapabilities=CAP_NET_BIND_SERVICE

RuntimeDirectory=headscale

[Install]
WantedBy=multi-user.target

Create the headscale user:

$ useradd headscale -d /home/headscale -m -s /bin/false

Change ownership of the data directory:

$ chown -R headscale:headscale /var/lib/headscale

Update the unix_socket path in /etc/headscale/config.yaml:

unix_socket: /var/run/headscale/headscale.sock

Reload SystemD:

$ systemctl daemon-reload

Start Headscale and enable it to start at boot:

$ systemctl enable --now headscale

Check the service status:

$ systemctl status headscale
# Look for "active (running)"

Check what ports Headscale is listening on (usually 8080 for HTTP, 9090 for gRPC):

$ ss -tulnp | grep headscale
# Example output:
# tcp LISTEN 0 1024 *:8080 *:* users:(("headscale",pid=...,fd=...))
# tcp LISTEN 0 1024 *:9090 *:* users:(("headscale",pid=...,fd=...))

Managing Users in Headscale

Tailscale uses "tailnets" - separate network groups that don't talk to each other. You can read more about this in Tailscale's docs: What is a tailnet?. In Headscale, these are called "users." You need to create at least one user before connecting devices to your network.

Create Users via Command Line

To create a user named default:

$ headscale users create default
# Expected output: "User created"

To see your users:

$ headscale users list
# Example output:
# ID | Name | Username | Email | Created
# 1  |      | default  |       | 2025-05-26 05:03:48

If you used Sealos to deploy Headscale, click the "Terminal" button on the Headscale app details page to open a terminal:

Then run the commands above to create your user.

Create Users with Headplane

Headplane is a web interface for managing Headscale. It needs an API key to connect to your Headscale server. First, generate an API key.

Run this command on your Headscale server (or in the Sealos terminal):

$ headscale apikeys create
# Copy the generated API key. Keep it safe like a password.

Enter the API key in Headplane's settings page. After connecting, go to "Users" at the top, then click "Add a new user":

Connect Tailscale Clients to Headscale

Tailscale clients on all major platforms can connect to custom control servers like Headscale. Older iOS clients worked a bit differently, but modern versions are simpler.

OS	Works with Headscale	Notes
Linux	Yes	CLI and GUI clients. Good for relay nodes.
OpenBSD	Yes	CLI client.
FreeBSD	Yes	CLI client.
macOS	Yes	GUI and CLI. See macOS docs.
Windows	Yes	GUI interface. See Windows docs.
Android	Yes	GUI interface. Server can be changed.
iOS	Yes	GUI interface. See iOS docs.

Here's how to set up Tailscale clients on different platforms.

Connect Linux Clients

Tailscale has official packages for Linux distributions. But users in some regions (like China) might get slow downloads from official repos. Tailscale also offers static binaries you can download directly.

Download the static version:

# Replace 1.XX.Y with the latest version and amd64 with your architecture
$ wget https://pkgs.tailscale.com/stable/tailscale_1.XX.Y_amd64.tgz

Extract it:

$ tar zxvf tailscale_1.XX.Y_amd64.tgz
# Creates a directory like tailscale_1.XX.Y_amd64/ with the binaries

Install the binaries:

$ sudo cp tailscale_1.XX.Y_amd64/tailscaled /usr/sbin/tailscaled
$ sudo cp tailscale_1.XX.Y_amd64/tailscale /usr/bin/tailscale

Copy the systemd service files:

$ sudo cp tailscale_1.XX.Y_amd64/systemd/tailscaled.service /lib/systemd/system/tailscaled.service
$ sudo cp tailscale_1.XX.Y_amd64/systemd/tailscaled.defaults /etc/default/tailscaled

Start the service:

$ sudo systemctl enable --now tailscaled

Check that it's running:

$ sudo systemctl status tailscaled
# Look for "active (running)"

Now connect your Linux client to Headscale:

# Replace <HEADSCALE_PUB_ENDPOINT> with your server's public IP or domain.
# Use the right protocol (http/https) and port from your config.yaml.
$ sudo tailscale up --login-server=http://<HEADSCALE_PUB_ENDPOINT>:8080 --accept-routes=true --accept-dns=false

# If you used Sealos deployment, HTTPS is usually set up already.
# Replace <SEALOS_HEADSCALE_DOMAIN> with your Sealos domain.
$ sudo tailscale up --login-server=https://<SEALOS_HEADSCALE_DOMAIN> --accept-routes=true --accept-dns=false

You can also get connection commands from Headplane's "Machines" page, which fills in the server URL for you.

Use --accept-dns=false at first to stop Headscale's MagicDNS from changing your system DNS settings. Only enable it if you need it and have set it up properly.

After running tailscale up, you'll see a registration link:

To authenticate, visit:

    https://headscale-your-instance.example.com/register/nodekey_xxxxxxxxxxxxxxxxxxxxxxxxxx

Open this link in your browser. The page will show you a command to run on your Headscale server to register the device. Or you can use Headplane: copy the node key (the long string after /register/), go to "Machines" in Headplane, click "Add Device," paste the key in the Machine Key field, pick an Owner (the Headscale user), and click "Confirm."

After registration, you'll see the device info in Headplane:

Back on your Linux machine, Tailscale sets up the network automatically. This includes a network interface (like tailscale0), routing tables, and iptables rules. To check the Tailscale routing table:

$ ip route show table 52

To check iptables rules for Tailscale (if you use iptables):

$ sudo iptables -S | grep tailscale
$ sudo iptables -S -t nat | grep tailscale

Set Up macOS Clients

There are three ways to install Tailscale on macOS:

App Store: Get the app from the Mac App Store.
Direct download: Download the .pkg installer or .zip file from Tailscale's website.
Command line: Install the CLI tools. See the macOS documentation for details.

All three use the same networking code. They just differ in packaging and whether they have a GUI.

Feature	App Store	Standalone App	Command Line
GUI	Yes	Yes	No
Background Running	No	Yes	Yes
Automatic Updates	Yes	Yes	Manual
Open Source	No	No	Yes
File Transfer	Yes	Yes	No

{{< alert >}}
Important: Pick either the App Store version or the standalone version. Don't install both.
{{< /alert >}}

After installing the Tailscale app, you need to configure it to use your Headscale server. Your Headscale server has setup instructions at https://<YOUR_HEADSCALE_PUBLIC_ENDPOINT>/apple.

For Tailscale versions 1.34.0 and later:

Hold Option (⌥) and click the Tailscale icon in your menu bar.
Hover over the Debug menu.
Select "Custom Login Server..." then "Add Account..." or "Change server...".
Enter your Headscale URL (e.g., https://<YOUR_HEADSCALE_DOMAIN>). Make sure to include http:// or https://. Click "Add Account" or "Save."
Tailscale will connect to your Headscale server and open a registration page in your browser.
Register the device the same way as Linux: copy the node key, go to "Machines" in Headplane, click "Add Device," paste the key, pick an Owner, and click "Confirm."

Test connectivity by pinging another device in your network:

$ ping -c 2 100.64.0.1 # Ping another device's Tailscale IP
# Expected output:
# PING 100.64.0.1 (100.64.0.1): 56 data bytes
# 64 bytes from 100.64.0.1: icmp_seq=0 ttl=64 time=37.025 ms

You can also use the Tailscale CLI if available:

$ /Applications/Tailscale.app/Contents/MacOS/Tailscale ping 100.64.0.1
# Expected: pong from device-name (100.64.0.1) via ... in Xms

For older Tailscale versions (before 1.32.0), the setup might be different. Check your Headscale server's /apple page for specific instructions.

Connect Android Clients

Android Tailscale has supported custom servers like Headscale since version 1.30.0. Download it from Google Play or F-Droid.

Open the Tailscale app. You'll see the login screen:

Tap the three-dot menu (⋮) in the top right. You'll only see an About option at first:

Here's a trick to unlock the custom server option: quickly tap to open and close the three-dot menu about 5-7 times. A Change server option will appear:

Tap Change server and enter your Headscale URL (e.g., https://<YOUR_HEADSCALE_DOMAIN>). Include http:// or https://:

Tap Save and restart. After restart, tap Sign in with other.... You'll go to your browser for registration:

Copy the machine key from the page. Register it on your Headscale server or via Headplane like before. After registration, go back to the app - it should show as connected:

Connect Windows Clients

To connect Windows Tailscale to Headscale, follow the instructions on your Headscale server's Windows page. Open https://<HEADSCALE_PUB_ENDPOINT>/windows in your browser. This page shows you how to set it up, usually by editing the Windows Registry or using command-line parameters:

Follow the instructions carefully. You'll usually edit registry entries to set the ControlURL or use parameters like /custom-server=<YOUR_HEADSCALE_URL> when installing or running Tailscale. After making changes, start the Tailscale client. It should open your browser for Headscale authentication, just like Linux and macOS.

Connect Other Linux Devices

Many people run Linux on routers (OpenWrt) or NAS systems (QNAP, Synology). The community has made tools for installing Tailscale and connecting to Headscale on these devices:

OpenWrt: Check out adyanth/openwrt-tailscale-enabler for scripts and packages.
Synology NAS: Tailscale has official packages. See tailscale/tailscale-synology.
QNAP NAS: Tailscale has official QNAP packages: tailscale/tailscale-qpkg.

Check the documentation in these repositories or your device's forums for setup instructions. These devices work great as subnet routers.

Connect iOS Clients

To use Tailscale on iPhone/iPad with Headscale, download the official app from the App Store. You might need an Apple ID from a region where Tailscale is available.

Download the Tailscale iOS app.
Open the app.
Tap the account icon in the top-right, then "Log in...".
On the login screen, tap the options menu (three dots or gear) and choose "Use custom coordination server".
Enter your Headscale URL (e.g., https://<YOUR_HEADSCALE_DOMAIN>) and tap "Log in". You'll go to your Headscale authentication page.
Register the device like before:
- Copy the machine key from the browser.
- Go to "Machines" in Headplane, click "Add Device," paste the key, pick an Owner, and click "Confirm."
- The iOS app will show the connection status and IP address.

Auto-Register Devices with Pre-Auth Keys

Headscale has "Pre-Authkeys" that let devices join automatically without manual approval each time. This is useful when adding many devices or automating setups.

Generate a pre-auth key for your user:

# Create a key for 'default' user that expires in 24 hours
$ headscale preauthkeys create --user default --expiration 24h
# Output includes: Key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

List your pre-auth keys:

$ headscale preauthkeys list --user default
# Shows: ID, Key, Reusable, Ephemeral, Used, Expiration, Created

You can also create keys in Headplane. Go to "Pre-auth keys" and click "Add a new Pre-auth key":

Set the user, expiration time, and whether it's reusable (multiple devices can use it) or single-use. Click "Confirm":

View and manage your keys:

Now devices can join automatically using the --authkey parameter:

# Replace $AUTH_KEY with your actual key
# Replace <HEADSCALE_PUB_ENDPOINT> with your server address
$ sudo tailscale up --login-server=http://<HEADSCALE_PUB_ENDPOINT>:8080 --accept-routes=true --accept-dns=false --authkey=$AUTH_KEY

The device will register automatically under the user associated with the key.

Set Up Subnet Routing

So far, we've built a mesh network where Tailscale devices talk directly using their Tailscale IPs (usually 100.x.x.x). But Headscale and Tailscale can do more. You can let any Tailscale device access an entire local network behind another Tailscale device. This subnet routing has many uses:

Access your home NAS, printers, and smart devices from anywhere.
Connect to internal work servers remotely.
Advanced: Access Kubernetes pod and service IPs by making K8s nodes subnet routers.

Say you have a Linux machine on your home network (like an OpenWrt router, Raspberry Pi, or any Linux server) running Tailscale and connected to Headscale. You want other Tailscale clients (like your laptop when you're away) to reach any device on your home network using their local IP addresses (like the 192.168.100.0/24 subnet).

Here's how to set up subnet routing:

Enable IP forwarding on the router:
On the Linux machine that will route traffic (like your OpenWrt router), enable IP forwarding:

# Enable IPv4 forwarding
$ echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/ipforwarding.conf
# Enable IPv6 forwarding if needed
$ echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/ipforwarding.conf
# Apply changes now
$ sudo sysctl -p /etc/sysctl.d/ipforwarding.conf

Advertise routes from the router:
Add --advertise-routes=192.168.100.0/24 to tell Headscale this device can route traffic for that subnet. If Tailscale is already running, use --reset to apply the new config:
```
# Replace <HEADSCALE_PUB_ENDPOINT> with your server address
$ sudo tailscale up --login-server=http://<HEADSCALE_PUB_ENDPOINT>:8080 --accept-routes=true --accept-dns=false --advertise-routes=192.168.100.0/24 --reset
```
For multiple subnets, separate with commas: --advertise-routes=192.168.100.0/24,10.0.0.0/8.

Enable the routes on Headscale:
After a device advertises routes, you must enable them on the Headscale server before other clients can use them.

Using Headplane:
Go to the router device's details page, click "Machine Settings" → "Edit route settings":

Find the advertised route (like 192.168.100.0/24) and toggle it to "Enabled":

Using command line:
Find your router node's ID:

$ headscale nodes list | grep your-router-hostname
# Example output:
# ID | Hostname             | ...
# 6  | openwrt-router       | ...

# List routes for the node
$ headscale routes list --node-id 6
# Example output:
# Route            | Enabled | Node
# 192.168.100.0/24 | false   | openwrt-router

Enable the route:

$ headscale routes enable --node-id 6 --route "192.168.100.0/24"
# Output: Route enabled

To enable all routes for a node at once:

$ headscale routes enable --node-id 6 -a

Accept routes on client devices:
Make sure client devices that need subnet access use --accept-routes=true. If they're already running without this, reconfigure them with --reset:

# On a client that needs subnet access
$ sudo tailscale up --login-server=http://<HEADSCALE_PUB_ENDPOINT>:8080 --accept-routes=true --accept-dns=false --reset

Check the routing table to confirm it's working:

# On a Linux client
$ ip route show table 52 | grep "192.168.100.0/24"
# Expected output (gateway IP will be your router's Tailscale IP):
# 192.168.100.0/24 via <ROUTING_NODE_TAILSCALE_IP> dev tailscale0 scope link

With subnet routing set up, you can now access any device on your home network's 192.168.100.0/24 subnet from any Tailscale client with --accept-routes enabled. Whether you're at work, a coffee shop, or traveling, you can reach your home devices using their local IP addresses.

Summary

Tailscale and Headscale work well for stability, ease of use, and NAT traversal. They beat many older or more complex VPN options. This comes from Tailscale's work on user-space NAT traversal techniques, especially their DERP server network. They wrote a good article about this: How NAT traversal works.

Here's a simple diagram showing how Tailscale nodes connect, with help from a coordination server (Headscale) and DERP relays for difficult NAT situations:

This guide should help you build your own private, secure VPN with Headscale. You get full control over your network.

My next article will cover how to set up custom DERP servers with Headscale. This will improve connection quality, especially for devices behind difficult firewalls, and give you complete control over your VPN infrastructure.

Kubernetes CRD Magic: Embedding Terminals Directly on Your Webpage

Carson Yang — Mon, 04 Sep 2023 07:44:26 +0000

In the realm of Kubernetes, utilities such as kubectl and helm serve as our principal conduits for cluster interaction. Yet, occasions arise when one might desire to instantiate a terminal directly on a webpage, bypassing the need to embed and configure these instruments locally. This treatise plunges into the intricate details of procuring this capability via Kubernetes Custom Resource Definitions (CRD), elucidating its architectural and practical facets through a tangible illustration.

The App Launchpad and Database suites within Sealos have distilled the Kubernetes resource layer's intricacies into the application stratum. Nonetheless, for more multifaceted situations, a more innate interaction with Kubernetes becomes essential.

Outlined below is the engagement with the K8s API Server via the Terminal:

Assessing Pod assets (Kubernetes' elemental scheduling unit, housing the actual container resources):

$ kubectl get pod

Surveying storage pvc resources (container-mounted storage assets, akin to those delineated in App Launchpad):

$ kubectl get pvc

Advanced Terminal Endeavors

The Terminal facilitates a plethora of sophisticated tasks.

Seamless Integration of Terminal & App Launchpad

Direct entry into each application container's terminal is achievable through the terminal app. Imagine deploying an entity like Nginx under application governance. Navigate to Nginx application's detailed interface, select the ellipsis on the detailed section's rightmost edge, and upon choosing 'Terminal', one is ushered into the Nginx application's terminal.

Unhindered Bridging of Terminal & Database

Establish an immediate linkage with the database, orchestrated in the Database App, right from the terminal.

Transition to the database's comprehensive view, and opt for the 'connect' to the left, Transition seamlessly to the Terminal and establish a direct connection with the database.

Feature Dissection

This capability's nucleus is a Kubernetes CRD christened Terminal. End-users can inaugurate a novel Terminal CRD on the webpage, post which a new Terminal materializes. This Terminal possesses rights to the designated Kubernetes Namespace, enabling execution of commands such as kubectl and helm.

Here's an archetype of a Terminal CRD:

spec:
  apiServer: https://kubernetes.default.svc.cluster.local:443
  ingressType: nginx
  keepalived: 4h
  replicas: 1
  token: xxxxx
status:
  availableReplicas: 1
  domain: https://xxxxxx.cloud.sealos.io

CRD Field Analysis

Within the spec segment of the Terminal CRD, each field is delineated as:

apiServer: Kubernetes API server's nexus. Employed by the Terminal for liaisons with the Kubernetes API.
ingressType: Ingress controller variety, either nginx or apisix.
keepalived: Terminal's duration. For instance, 4h denotes an automatic dissolution of the Terminal 4 hours post-inception.
replicas: The Terminal's replication count. Presently, only a solitary replica is endorsed.
token: Authentication token for the Kubernetes API server, harnessed for Terminal's authentication.

The status portion dissects each domain as:

availableReplicas: The tally of available replications.
domain: The nexus employed for web-based Terminal interactions.

Upon the Terminal CRD's origination, a fresh Terminal manifests on the webpage. Users are equipped to run commands like kubectl and helm within this Terminal.

Architectural Blueprint & Execution

The Terminal feature's blueprint and realization comprise several pivotal elements:

Terminal Steward

The Terminal Steward stands as the linchpin of the Terminal functionality, vigilantly overseeing the genesis, modification, and dissolution events of the Terminal CRD and adapting in response.

Terminal Capsule

The Terminal Capsule epitomizes the live Terminal, hosting a bespoke Docker image laden with command-line apparatuses like kubectl and helm, alongside a web terminal server, such as ttyd. The embedded web terminal server hearkens to port 8080, delivering web terminal services.

Service & Gateway

Every Terminal CRD sees the Terminal Steward instituting a corresponding Kubernetes Service and Gateway. The Service channels traffic to the Terminal Capsule, while the Gateway navigates external access petitions to the Service.

Terminal Docker Imagery

The Docker imagery for the Terminal Capsule, founded on Ubuntu 20.04, is embellished with command-line tools including kubectl, helm, and the ttyd web terminal server. Moreover, it is augmented with MySQL, MongoDB, and Redis clients, facilitating users to connect and govern these databases directly within the Terminal.

The image's fabrication sequence unfolds as:

Integrate vital software packages, spanning kubectl, helm, vim, and beyond.
Implant the web terminal server ttyd and an initialization script start-terminal.sh.
Designate the ttyd server to port 8080 and calibrate its initiation parameters, which encompass the Kubernetes API server nexus and access token.

Terminal's Dissolution & Longevity

The Terminal Steward wields Kubernetes' Finalizer mechanism to address the Terminal CRD's termination events. As a Terminal CRD meets its end, the Finalizer postpones Kubernetes from immediate eradication, holding out for the Terminal Steward to clear out resources tied to the Terminal CRD (like Deployment, Service, and Gateway) before the CRD's removal.

Furthermore, the Terminal Steward capitalizes on the Keepalive mechanism, autonomously eliminating lapsed Terminal entities. The Terminal longevity, designated by the keepalived field, triggers its erasure once its existence surpasses the stipulated keepalived duration.

Interaction Schema Between the User Interface and Backend Systems

Outlined below is the meticulous progression from the moment a user engages the Terminal button to when they gain access to the Terminal:

Users activate the Terminal button on a web interface, instigating a backend request. This petition encompasses details regarding the Terminal's configuration, such as its designated Kubernetes Namespace and predetermined lifespan.
Upon assimilation of the request, the backend system spawns a novel Terminal CRD (Custom Resource Definition) infused with the Terminal's specific configuration attributes.
The vigilant Terminal Controller, upon discerning the genesis of a new Terminal CRD, orchestrates the appropriate Terminal Pod. This specific Pod operates a Docker image replete with command-line tools like kubectl, helm, and an embedded web terminal server.
Concurrently, the Terminal Controller commissions a corresponding Kubernetes Service and Ingress. This Service navigates network traffic towards the Terminal Pod, whilst the Ingress directs external solicitations to the said Service.
Posthaste, the backend system extracts the Terminal's domain information from the status segment of the Terminal CRD, relaying this domain to the frontend system.
Upon reception of the Terminal's domain, the frontend system projects it onto a fresh browser tab, furnishing users with a pristine Terminal. Within this environment, users are equipped to invoke commands such as kubectl, helm, and more.

Tailored Configurations

Assorted Ingress Controller Compatibility

The Terminal is adept at liaising with a plethora of Ingress Controllers, notably Nginx and Apisix. Users are thus empowered to elect an Ingress Controller that resonates with their distinct requirements.

Adjustable Lifespan Setting

End-users possess the prerogative to delineate the Terminal's duration of existence. Post a specified interval subsequent to its creation, the Terminal will be autonomously terminated. This strategy circumvents the undue occupation of resources by dormant Terminals.

Prospective Enhancements

Augmented Command-line Instrument Integration

Anticipated versions shall incorporate an expansive set of command-line tools within the Terminal Docker image, encompassing tools like istioctl, kn, and beyond, bestowing users with a more extensive operational gamut.

Expanded Ingress Controller Affiliation

There are blueprints to embrace supplementary Ingress Controllers such as Traefik and HAProxy, thereby diversifying users' available choices.

WebSocket Channelization

The inauguration of a WebSocket service through Ingress is cardinal. This facilitates users to inaugurate a terminal within the web facade and liaise with the Kubernetes cluster via WebSockets. When juxtaposed against HTTP, WebSockets proffer a superior real-time bi-directional communication channel, amplifying user engagement.

Granulated Access Governance

The incorporation of a refined access governance mechanism is paramount. With imminent enterprise collaborative modules, a myriad of users could coalesce within namespaces. Consequently, the terminal will access distinct user realms—be it managerial or developmental—relying on the permissions procured.

Assimilation of Diverse Development Apparatuses

Beyond the realms of kubectl and helm, the Terminal aspires to amalgamate a variety of developmental and debugging tools, including but not limited to git, curl, jq, and so forth.

User-Centric Customizations

End-users will be capacitated to modify the Terminal's visual aesthetics, such as chromatic themes, typographic dimensions, and more. Additionally, they can calibrate behavioral configurations like the archival depth of command histories, tactile shortcuts, among others.

Epilogue

Leveraging Kubernetes' CRD capabilities, we can seamlessly induct a robust Terminal within a web framework. Within this Terminal, users can seamlessly deploy an array of commands, fostering a more intimate rapport with the Kubernetes cluster. This not only optimizes their procedural workflows but also profoundly elevates their overarching interaction experience.

Revolutionizing Database Services: An Inside Look at Sealos and KubeBlocks

Carson Yang — Tue, 29 Aug 2023 10:55:05 +0000

Greetings to all readers! Today, we present an exquisite overview of the database services rendered by Sealos. KubeBlocks, an esteemed backend service provider, assures uninterrupted functioning of your database applications on Sealos. Regardless of employing it in a public domain or a local setup, Sealos deftly manages relational databases, NoSQL, vector databases, and streaming databases. This platform is tailored for professional environments, guaranteeing dependable, top-tier, transparent, and economically viable data infrastructure.

Let us embark on an exploration of the allure of database applications:

Feature Overview

Database Genesis

Sealos presents an intuitive database frontend platform, effectively obviating intricate command-line tasks. Via this platform, one can effortlessly instantiate diverse database categories, encompassing Mysql, PostgreSQL, MongoDB, Redis, and an expansive list beyond these.

Connection Dynamics

Upon entering the specifics page, one can scrutinize comprehensive database information and engage with it via a singular connection action. This streamlines procedures, augmenting your database interactivity quotient.

Assured Uptime Examination

Sealos shines in bestowing unparalleled uptime services, fortifying databases against untimely disruptions. This confers an augmented security layer to your repositories, facilitating a tranquil utilization. Our assertion of database resilience is corroborated with a succinct demonstration.

To commence, instantiate a database application with plural instances; in this case, a 3-instance PostGreSQL. Post-instantiation, one can interface with the database command terminal using the singular connection feature. We activate the Add a Terminal function to instantiate a secondary terminal module.

Subsequently, we identify test-postgresql-1 as the reigning master node. We then expeditiously remove this principal node employing the kubectl delete pod test-postgresql-1 command.

Restoration Capabilities

Our database also boasts a formidable backup and revival feature, assuring that even amidst data compromisation or loss, restoration to the backed-up state is effortless. Be it inadvertent deletions or calamitous events, these backups ensure rapid database reconstitution, curtailing operational stagnation.

For illustration, I have pre-curated data.

Navigate to the backup archive and activate the "Backup" button to commence the archival process. Herein, the manual archival method is showcased. Backup titles and annotations are modifiable; post modifications, one simply engages the "Start Backup" button.

Once the backup is completed, you can check the results through its status. You can click the "restore" icon to initiate the recovery process and wait for the restored database to successfully start.

Enter the restored database to view the data, and you will find the data successfully recovered.

Surveillance Capabilities

Within Sealos, beyond mere database management, you’re granted access to intuitive monitoring utilities. The operational status of your database is always at your fingertips, and its efficiency can be ascertained through graphical representations and metrics.

Functional Underpinnings

The prowess of KubeBlocks in proffering steadfast and adept database services on Sealos may pique your curiosity. Let's journey into its operational paradigms and fathom its resilient architecture and data recovery stratagems.

Design Paradigm for Stateful Services

KubeBlocks adeptly architects database topologies. With the Replicated State Machine (RSM) and its replication interrelations as its nucleus, it morphs intricate distributed databases into integrated foundational modules (blocks). Stateless, StatefulSet, or RSM, all seamlessly integrate within KubeBlocks. This facilitates the amalgamation of any database engine with KubeBlocks, birthing a dynamic system framework.

Resilient Architectural Blueprint

KubeBlocks inculcates dual resilience algorithms: consensus-driven and traditional primary-secondary. In consensus-driven databases, KubeBlocks oversees role discernment, rectification, and restructuring. The database autonomously manages thorough detection, adjudication, and transition tasks. For archetypal primary-secondary contexts, like MySQL and PostgreSQL pairings, KubeBlocks supervises detection, decision-making, transition, reconstruction, and role rectification. Moreover, its universal resilience blueprint accommodates myriad database categories such as replicated clusters and segmented clusters, amplifying reliability by enhancing replica counts and diminishing data loss chances.

Data Salvage Blueprint

To bolster data safety, KubeBlocks introduces a salvage and revival strategy. Backups cater to diverse scenarios such as data misplacement, calamity recovery, and data transference. On Sealos, a tangible backup feature is offered, signifying a direct replication of the database's corporeal files (both data and log) onto backup mediums like storage disks or tapes. These tangible backups are marked by swift restorations, consistent data, and storage optimization. Their efficiency in restoring backup files to the original database, preserving physical congruence with the database, and conserving storage space is unmatched. This makes it a premier choice for substantial databases, further elevating Sealos's prowess for professional settings.

For those captivated by database solutions, Sealos is a commendable platform to explore. Whether a developer, data maestro, or systems curator, this robust database service promises enhanced data management and operations. Let Sealos elevate your data endeavors to celestial heights!

Do not falter; experience it firsthand!

Sealos Cloud Operating System — Simplicity, Affordability, and Liberation in Cloud Management

Carson Yang — Mon, 21 Aug 2023 09:30:04 +0000

A Grand Vision

It is a magnificent and captivating plan.

One quiet night in 2018, I sat at my keyboard and typed the first line of code for Sealos. Initially, the repository was named "kubeinit," but I soon realized that the scope was too narrow. I couldn't just create a tool for installing Kubernetes. Installation was merely a piece of a larger puzzle. Thus, it was renamed Sealos, and a grand cloud operating system vision was conceived!

After completing the first version of Sealos, I released it for sale on the Alibaba Cloud Marketplace for 15 yuan per copy. I never anticipated that people would actually purchase it. When I received the first 15 yuan payment, I was incredibly excited, as if a business empire was unfolding before my eyes. However, the reality was that I spent an entire day providing after-sales service to that customer... I was still resolving issues for users even while at the cinema!

Soon, sales soared, and I quickly upgraded to a new iPhone 8. However, the number of issues also increased simultaneously, to the point where I couldn't provide timely after-sales support to everyone. So, I decided to rewrite Sealos and released version 2 based on Ansible. But in the end, I felt that I hadn't achieved perfection because users still faced too many dependency-related problems. It wasn't until I finished reading the source code of kube-proxy that I discovered a solution to simplify load balancing and eliminate all dependencies. That's when I developed Sealos version 3, which achieved the pinnacle of installation simplicity.

Why focus on installation initially?

Installation is the entry point, and most people learning cloud-native technologies cannot avoid this issue. The flow of installation is significant, making it an excellent starting point. Once users become accustomed to using Sealos for installation, they will gradually explore its other functionalities.

Working at Alibaba

During my time at Alibaba, I developed Sealer. The most important aspect here was to make installation highly flexible. Previously, users could only use the installation package I created, but the innovation of cluster imaging allows users to define their own installation packages and freely combine any packages. Here's a thought that makes me proud: If we consider the entire cluster as a whole and view Kubernetes as an operating system, what would a "cloud version Docker image" look like within this cloud operating system? Undoubtedly, this is a great concept that offers high levels of abstraction and flexibility.

dockerfile
FROM kubernetes:v1.25.0
COPY mysql .
CMD helm install mysql .

This concept allows the cloud operating system to have "images" just like a standalone operating system. Another step is completed in this grand vision.

The First Year of Entrepreneurship

So, what will the Sealos cloud operating system ultimately become? That is an indescribable question, and I only have a vague vision of it. It wasn't until the continuous iteration of three versions during the entrepreneurial process that it took on its present form—Everything is an application!

Understanding this is actually quite simple. Just replace the standalone applications installed on a single machine operating system with various distributed applications. The entire data center will no longer appear as isolated servers but as a unified whole, transforming into a virtual supercomputer.

This sleek, refreshing, and near-perfect cloud operating system is bound to capture your heart from the moment you lay eyes on it!

This is my painstaking work of five years—Sealos! Dedicated to all of you~

The Cloud Can Be So Clean

Sealos maintains an extremely minimalist design with no unnecessary buttons. It achieves simplicity and powerful parallel functionality, which is sometimes as difficult as reaching the heavens. Nevertheless, we have put a great deal of effort into the product design. Regardless of who you are, using Sealos will immerse you in the comfortable experience we have crafted.
In the world of B2B software, the payer and the user are often not the same person, resulting in a neglect of the user experience. The most crucial thing is to convince decision-makers. However, Sealos is different. We firmly believe that the user experience surpasses everything else. If we dedicate a significant amount of energy to the product and ultimately fail, we will have no regrets.

The black, white, and gray design style will make you feel like you're drinking plain water while using the product, rather than a beverage, let alone footwash (as some products make you feel like dying). Developers already suffer enough, and I hope that using Sealos will bring you a pleasant mood.

Sealos can pinpoint the pain points of applications. For example, the App Launchpad, an application manager, allows you to launch your own application within 30 seconds. This involves numerous details, such as automatically configuring public domain names and resolving HTTPS certificate issues.

The Cloud Can Be So Affordable?

I have run over ten applications on Sealos, including three databases, a blog, a low-code platform, a testing platform, and more, all costing me only 4 yuan per day:

Why is it so affordable?

You only need to pay for the running containers, without the need for virtual machines or creating an entire Kubernetes cluster. It's open and ready to use.
Automatic scaling reduces the number of replicas to 1 during periods of low user traffic.
We can make full use of the elasticity of public clouds, write a significant amount of automation code, release computing resources during nighttime, and reduce costs.

For enterprises, this can significantly reduce resource utilization costs. We ourselves run over 7,000 applications on just 10 servers. What does that mean? After deploying a Sealos cluster, as long as the server resource utilization is below 70%, you can continuously add applications to the cluster until it reaches its capacity.

You might wonder, why not use Kubernetes directly? The reason is simple. For enterprises like Xunfei, applications are distributed across various departments, making multi-tenancy, isolation, and collaboration crucial. Using Kubernetes directly could disrupt the cluster, and the worst-case scenario is that a department or user inadvertently causes a security issue that crashes the entire cluster. Sealos perfectly solves this problem!

Sealos can help 80% of enterprises reduce their resource utilization costs by 80%.

The Cloud Can Be So Liberating

Unlike other management platforms or PaaS platforms, the core design principle of Sealos is "everything is an application." Different developers with different roles can use different applications, allowing each user to use the platform without any mental burden. It's similar to the Android ecosystem, where there are millions of applications, but you only care about the ones you use without worrying about what other applications are doing.

This design has two main advantages:

Seamlessly Use Sealos Whether You Understand Kubernetes or Not

Many Kubernetes-based PaaS platforms or distributions either expose a large number of native Kubernetes concepts or hide these concepts. Neither approach is ideal.

Exposing a large number of native concepts is unfriendly to beginners and novices, while hiding Kubernetes loses flexibility and compatibility, making it unfriendly for Kubernetes experts.

Sealos takes a different approach. On this platform, different people can use different applications. For example, if you're a developer who wants to write CRUD operations, you can directly use the Laf function application. If you're a DBA, you can directly use the database application. In this case, you don't need to care about Kubernetes at all as these concepts are completely abstracted.

If users are cloud-native experts, they can install Lens and various Kubernetes dashboards on Sealos. They can also open a terminal and use native commands. This greatly enhances flexibility.

Freedom to Assemble

Sealos pays great attention to the coordination between applications. For example, if you're using function compute on Sealos, the default database might be MongoDB. But what if you want to use PostgreSQL? In this case, you can install a PostgreSQL application on Sealos and access it directly within the function compute through service discovery. Since they are in the same cluster, they can directly communicate through internal DNS.

Sealos is streamlined yet not simplistic. All components can be uninstalled, allowing the cloud to perfectly meet your needs—more is considered excessive, less is considered insufficient. This also means that whether it's a single server or hundreds of data centers, they can be built into a cloud with just one command.

What Can Sealos Actually Do?

Run an nginx demo on Sealos in just 30 seconds with automatic scaling.
Start various databases in 30 seconds and connect to them directly within your business system's intranet.
Launch your business applications written in various programming languages directly on Sealos.

These three capabilities serve as the foundation, and you can gradually explore and discover new territories.

When it comes to running your own business, we have made many detailed optimizations for this scenario. For example, automatic allocation of subdomains, horizontal autoscaling, and support for running various stateful services.

You will find that with Sealos, whether you're deploying a monitoring system or running a low-code platform, it's all within reach. You can easily host your blog on Sealos at a low cost. Using the Sealos terminal, you can run any Kubernetes-compatible application without difficulty in automation.

Moreover, you'll discover that there is actually an AI helping you with automated fault diagnosis, automatic deployment of services, and even assisting you in code writing and automatic testing for deployment.

Then you'll realize that even ordinary people can use Sealos:

You can quickly install financial software on Sealos.
You can also quickly install a knowledge base on Sealos to write notes for everyone in the company.
You can even install a chat software on Sealos for internal communication and collaboration within the enterprise.

At this point, you'll be pleasantly surprised to discover that Sealos can do everything, truly versatile, and yet so simple! Ultimately, you'll come to understand that this is what a cloud operating system is!

Are People Really Using Sealos?

Absolutely, the Sealos community has over 100,000 users, including various large enterprises.

Within two months of its launch, Sealos has already surpassed 10,000 registered users, with a total of 7,000+ applications running on the cloud service.

Is Sealos only suitable for small-scale applications?

Certainly not. Among Sealos' customers is the National Health Big Data platform, which supported the health code service during the pandemic with high concurrency business that couldn't afford a single second of downtime. Sealos has also supported large-scale GPU clusters that process 80 terabytes of data daily, with a total of 80 petabytes of data in the entire cluster. The Judo Cloud platform runs hundreds of applications on Sealos.

The Roadmap

Sealos' grand vision goes beyond what has been accomplished so far. Our goal is to evolve into an omnipresent cloud operating system, providing people with a user-friendly cloud service experience akin to using a personal computer. With Sealos, enterprises can effortlessly achieve:

Rapid deployment of new businesses in just a minute.
A 50% reduction in costs within a year.
One-click creation of a cloud, as simple as flipping a switch.

For enterprise cloud needs, Sealos is the solution.

In the future, we will continue to uphold the spirit of craftsmanship and carefully craft common applications that enterprises require within the Sealos cloud operating system, such as databases, message queues, inference capabilities, and various programming language execution environments.

The Sealos cloud operating system will also incorporate a Copilot, acting as a navigator's assistant. It can automatically perform cloud-native transformations, helping developers easily enter the realm of cloud-native. It can also assist in diagnosing cluster issues, identifying security vulnerabilities, and providing professional operational advice like an expert.

Conclusion

After five years, Sealos has finally realized the vision I had when I wrote the first line of code—a cloud operating system.

I am grateful to the first person who paid me 15 yuan. Your trust and encouragement have been like a huge investment, giving me the strength to move forward.

I want to express my gratitude to all the contributors in the community, especially my fellow companion, Lao Cui, who has been with me throughout the journey.

Special thanks to Xunfei for refining complex business scenarios, which deepened my understanding of business scenarios.

I appreciate the support and assistance from Alibaba Cloud while developing Sealer. It laid a solid foundation for the underlying capabilities of the Sealos cluster image.

I am thankful to all the partners who embarked on this entrepreneurial journey with me. It is through everyone's efforts that the seed of inspiration has grown into a tangible reality.

I want to thank Qi Jia Chuang Tan for giving us the unexpected push, and most importantly, thank you Dr. Lu Qi for your unwavering confidence, which has given us great encouragement.

Thanks to Professor Li Jun, Dean Kang Yi, Professor Zhang Hailong, Gaojie Capital, and Jinfu Asset for their help, guidance, and trust.

I express my gratitude to every user who chose Sealos. Your understanding and patience throughout the iterative process have shaped a more perfect Sealos together with us.

To all the decision-makers who have chosen us, I wish to congratulate you on making a wise decision. Sealos has now reached a new starting point, and we will undoubtedly meet your expectations and deliver a perfect cloud operating system.

You are welcome to experience the charm of the Sealos cloud operating system at https://cloud.sealos.io/.

Boost Your Coding Efficiency with the Laf Assistant in VS Code

Carson Yang — Thu, 20 Apr 2023 03:49:22 +0000

Boost Your Coding Efficiency with the Laf Assistant in VS Code

To excel in one's work, one must first sharpen one's tools. In the realm of coding, an indispensable component is the Integrated Development Environment (IDE), which enables us to write code with greater efficiency and expedites the development process. Thus, the IDE becomes one of our most intimate companions in coding.

Although Laf Cloud Development offers a minimalistic Web IDE, enabling users to edit cloud functions anywhere with a simple browser,

many individuals still prefer to write cloud function code within an IDE.

Thanks to the development of laf-cli and the openness of APIs, Laf imposes no mandatory requirements on local code editors, which signifies that Laf can be used directly with VS Code or any other editor to compose, debug, publish, and update cloud functions.

laf-cli is an npm module that facilitates cloud function management, cloud storage management, and more for Laf Cloud Development via the command line. Utilizing the command line, I have created a VS Code extension: laf assistant

The experience of using Laf directly with VS Code is not flawless

VS Code is a free, open-source, cross-platform code editor developed and maintained by Microsoft, boasting an abundance of plugins and powerful features. Importantly, I am personally accustomed to using VS Code, as are a substantial number of developers.

Prior to the emergence of the laf assistant, I had experimented with the Laf-cli module for some time. Upon modifying a code segment and needing to debug it, I had to input rather complex commands.

For instance, if the cloud function is named "BatchTestDB," I would have to enter the command line: laf func exec BatchTestDB -l 9

Switching cloud functions necessitates manual command modification. When confronted with copious logs, the experience is as follows:

Another cumbersome issue is that the content output in the terminal is uneditable and lacks code folding. Inspecting extensive JSON data logs can be a particularly agonizing endeavor. As debugging progresses over time, the terminal becomes increasingly cluttered and overwhelming.

When it comes time to publish cloud functions, manual command line modification is once again required.

Laf Cloud Development's Web IDE is evidently more convenient and straightforward for debugging, publishing, and managing cloud functions than this approach. To seamlessly combine the outstanding advantages of the Web IDE with local development, I have contemplated developing a VS Code extension.

The Code-writing Experience of `Laf assistant`

Within the cloud function editor, right-click to publish, download, or execute cloud functions. Combined with VS Code's native remapping capabilities, I have remapped running cloud functions to ⌘+F1. Upon modifying and saving a cloud function, simply press ⌘+F1 to execute it.

I have directed log output to a new, editable, and foldable text file for increased convenience. If necessary, the log can be saved directly to a file, or the editor can be closed to discard the log content.

Code Version Control and Collaboration

Laf Cloud Development's Web IDE lacks a code system and version control. The Web IDE does not save all modified versions; instead, it retains them in the browser's local cache. This implies that inadvertent cache clearing or browser switching may result in the loss of drafts within the Web IDE editor. Collaborative development in multi-person projects can also be cumbersome.

In my opinion, the Web IDE is well-suited for rapid development and deployment of simple cloud functions, as well as temporary code modifications. However, in complex code situations, it cannot compare to the local development experience of VS Code.

Additionally, laf assistant allows management of frontend code and Laf cloud function code within a single project, facilitating comprehensive management of frontend and backend code. The Web IDE is also incapable of searching code, whereas having frontend and backend code in one project enables easy global searching.

When used in conjunction with Git, version control can be conveniently implemented.

Moreover, for collaborative development, laf assistant supports individual configuration of Laf API addresses and Laf application Appids for the same project on different computers. Each developer can debug and develop within their own Laf application, and upon code deployment, publish to the official application, thus avoiding test data contamination.

Subsequent Upgrade Plans for `laf assistant`

1. AI Empowerment

The interface has been essentially implemented. With a

In the future, within VS Code, AI will be able to automatically complete cloud function code with just a few clicks or keystrokes.

2. Enhance Cloud Storage Management

Locally compiled frontend code can be hosted in Laf's cloud storage with a single click.

3. Addition of More Debugging Modes for Cloud Functions

Custom debugging parameters will be available. Subsequent updates will also include real-time log monitoring, facilitating frontend debugging and log inspection.

4. Standalone Management Panel

By clicking the Laf icon in the sidebar, all Laf Cloud Development-related content will be centralized and displayed.

5. Further Detail Optimization

All developers are encouraged to provide suggestions for improvement, making laf-assistant even more user-friendly and invigorating the cloud development experience!

Construct a ChatGPT web demonstration page using Laf

Carson Yang — Mon, 27 Mar 2023 12:36:25 +0000

OpenAI has released the official ChatGPT API, powered by their newest model gpt-3.5-turbo, which is their most advanced model yet, with faster response times and cheaper pricing.

As developers, we want to integrate ChatGPT and related models into our own products and applications through the API. However, due to access restrictions, we need to use various API proxy services to access the ChatGPT API indirectly.

Even if we solve the API access problem, we still need to prepare a development environment, such as a Node.js environment for a Node.js client.

Is there a simple and fast way to call the ChatGPT API?

We can use Laf.

Laf is a fully open-source cloud development platform that provides out-of-the-box capabilities such as cloud functions, cloud databases, and object storage, allowing you to write code like writing a blog post.

GitHub: https://github.com/labring/laf

If you want to quickly learn how to use Laf, you can refer to this article: Learn Laf in Three Minutes.

Now, let's start the timer and use Laf to implement our own ChatGPT in three minutes!

Prerequisite: You need to have a ChatGPT account and generate an API Key (you can search on Google for this).

Cloud Function Tutorial

First, log in to laf.dev and create a new application.

Click the "Develop" button to enter the development page.

In the NPM Dependence panel, click the + in the upper right corner:

Then enter "chatgpt" and press enter to search, select the first search result, and click "save and restart":

After the restart, "chatgpt" will appear in the custom dependency items.

Now, create a new cloud function named send and write the following code:

import cloud from '@lafjs/cloud'
export async function main(ctx: FunctionContext) {
  const { ChatGPTAPI } = await import('chatgpt')
  const api = new ChatGPTAPI({ apiKey: cloud.env.CHAT_GPT_API_KEY })

  let res = await api.sendMessage('"鸡你太美" refers to which male artist in mainland China? Here\'s a hint: he likes to sing, dance, play basketball, and rap.')
  console.log(res.text)

  return res.text
}

API Key is passed through the environment variable CHAT_GPT_API_KEY, so we also need to create an environment variable. Click the settings icon in the lower left corner:

Select "Environment Variable" --> "Add Environment Variables" in turn, enter the name and value of the environment variable, and click "OK", then click "Update", and the application will be restarted.

Now click "Run" in the upper right corner to debug and run.

Perfect! Now let's try adding the context tracking feature. It's actually quite simple, just pass in the ID of the previous message during the conversation. Here's the code:

import cloud from '@lafjs/cloud'
export async function main(ctx: FunctionContext) {
  const { ChatGPTAPI } = await import('chatgpt')
  const api = new ChatGPTAPI({ apiKey: cloud.env.CHAT_GPT_API_KEY })

  let res = await api.sendMessage('"鸡你太美" refers to which male artist in mainland China? Here\'s a hint: he likes to sing, dance, play basketball, and rap.')
  console.log(res.text)

  // Pass in parentMessageId to track context
  res = await api.sendMessage('No, his surname is Cai. Please answer again.', {
    parentMessageId: res.id
  })
  console.log(res.text)

  return res.text
}

Let's run it and see:

Amazing! They got the answer right on the second try!

Okay, let's start the timer now, as the tutorial is finished and we are ready to implement our ChatGPT.

Cloud Function

Now we can start building our own ChatGPT. First, replace the function from the previous section with the following code:

import cloud from '@lafjs/cloud'

export async function main(ctx: FunctionContext) {
  const { ChatGPTAPI } = await import('chatgpt')
  const data = ctx.body

  // Put the api object into cloud.shared so that we can track context
  let api = cloud.shared.get('api')
  if (!api) {
    api = new ChatGPTAPI({ apiKey: cloud.env.CHAT_GPT_API_KEY })
    cloud.shared.set('api', api)
  }

  let res
  // If parentMessageId is passed in from the front-end, it means we need to track context
  if (!data.parentMessageId) {
    res = await api.sendMessage(data.message)
  } else {
    res = await api.sendMessage(data.message, { parentMessageId: data.parentMessageId })
  }
  return res
}

Now it should be easy to understand this function, right?

Front-end

We need a front-end page for our Web version of ChatGPT. First, we need to install the Laf SDK:

$ npm install laf-client-sdk

Next, we need to create a cloud object:

import { Cloud } from "laf-client-sdk"; 

// Create a cloud object, replace <appid> with your own App ID
const cloud = new Cloud({
  baseUrl: "https://<appid>.laf.dev",
  getAccessToken: () => "", // No need for authorization here, leave it blank for now
});

Now let's take a look at the core code of the front-end, which is very simple, just pass the question and context ID to the cloud function:

async function send() {

  // The question we are asking
  const message = question.value;

  let res;
  // Same logic as the cloud function, pass in context ID if there is one
  if (!parentMessageId.value) {
    res = await cloud.invoke("send", { message });
  } else {
    res = await cloud.invoke("send", { message, parentMessageId: parentMessageId.value });
  }

  // The answer to our question is in res.text

  // This is the context ID
  parentMessageId.value = res.id;
}

With a little bit of additional detail, we can make it look like this:

After adding these details, the basic development work is done. Now it's time to deploy the project and share it with your friends, and maybe have a drink or two.

Speaking of deployment, we should now go buy a server, install Nginx, configure Nginx, set up domain name resolution, bind the domain name...

NO NO NO, I don't allow you to waste your young and beautiful life. Life is short, you need Laf. 😃

Deploy

Open your Laf and navigate to the storage interface. Click on the "+" sign above and create a storage bucket with read-only permissions (you can choose any name).

After creating the bucket, run the build command in your front-end project (I used npm run build).

Once the build is complete, locate the dist folder and upload everything inside it to the storage bucket you just created, just as I did. Remember to upload everything as is, files are files, and folders are folders.

Once the upload is complete, you will notice an option in the top right corner to "Enable website hosting". Click on it!

After clicking, a link will appear. Click on it to see what it is.

Oh my goodness! Isn't this the project I just developed?!

Congratulations! Your project is now online. Share it with your friends!

Project source code: https://github.com/zuoFeng59556/chatGPT
Example website: https://lafai.io/

DEV Community: Carson Yang

Headscale Deployment and Usage Guide: Mastering Tailscale's Self-Hosting Basics for Ultimate Control

What is Tailscale?

What is Headscale?

How to Deploy Headscale

Quick Deploy with Sealos

Deploy on a Linux Server

Managing Users in Headscale

Create Users via Command Line

Create Users with Headplane

Connect Tailscale Clients to Headscale

Connect Linux Clients

Set Up macOS Clients

Connect Android Clients

Connect Windows Clients

Connect Other Linux Devices

Connect iOS Clients

Auto-Register Devices with Pre-Auth Keys

Set Up Subnet Routing

Summary

Kubernetes CRD Magic: Embedding Terminals Directly on Your Webpage

Advanced Terminal Endeavors

Seamless Integration of Terminal & App Launchpad

Unhindered Bridging of Terminal & Database

Feature Dissection

CRD Field Analysis

Architectural Blueprint & Execution

Terminal Steward

Terminal Capsule

Service & Gateway

Terminal Docker Imagery

Terminal's Dissolution & Longevity

Interaction Schema Between the User Interface and Backend Systems

Tailored Configurations

Assorted Ingress Controller Compatibility

Adjustable Lifespan Setting

Prospective Enhancements

Augmented Command-line Instrument Integration

Expanded Ingress Controller Affiliation

WebSocket Channelization

Granulated Access Governance

Assimilation of Diverse Development Apparatuses

User-Centric Customizations

Epilogue

Revolutionizing Database Services: An Inside Look at Sealos and KubeBlocks

Feature Overview

Database Genesis

Connection Dynamics

Assured Uptime Examination

Restoration Capabilities

Surveillance Capabilities

Functional Underpinnings

Design Paradigm for Stateful Services

Resilient Architectural Blueprint

Data Salvage Blueprint

Sealos Cloud Operating System — Simplicity, Affordability, and Liberation in Cloud Management

A Grand Vision

Why focus on installation initially?

Working at Alibaba

The First Year of Entrepreneurship

The Cloud Can Be So Clean

The Cloud Can Be So Affordable?

The Cloud Can Be So Liberating

Seamlessly Use Sealos Whether You Understand Kubernetes or Not

Freedom to Assemble

What Can Sealos Actually Do?

Are People Really Using Sealos?

The Roadmap

Conclusion

Boost Your Coding Efficiency with the Laf Assistant in VS Code

Boost Your Coding Efficiency with the Laf Assistant in VS Code

The experience of using Laf directly with VS Code is not flawless

The Code-writing Experience of Laf assistant

Code Version Control and Collaboration

Subsequent Upgrade Plans for laf assistant

1. AI Empowerment

2. Enhance Cloud Storage Management

3. Addition of More Debugging Modes for Cloud Functions

4. Standalone Management Panel

5. Further Detail Optimization

The Code-writing Experience of `Laf assistant`

Subsequent Upgrade Plans for `laf assistant`