Oliver Conzen

Non-Stop Action on a Budget: GitHub Actions on Oracle Free Tier

Fri, 24 Apr 2026 00:00:00 GMT

Running CI/CD on someone else's computer is convenient until it isn't. Between minute pricing, queuing during busy periods, and limited customization, GitHub-hosted runners hit limits fast. This post breaks down how I run a self-hosted GitHub Actions fleet on an Oracle Cloud Ampere instance (4 cores, 24GB RAM, 150GB disk) managed entirely through GitOps. The goal: stop paying for CI and run it for free instead, with room to scale to Hetzner Cloud if the workload outgrows the free tier.

The Hardware

The entire setup lives on a single Oracle Cloud Infrastructure (OCI) Always Free Ampere A1 instance:

Resource	Spec
CPU	4 Arm cores
RAM	24 GB
Disk	150 GB
Cost	$0 (Always Free tier)

Yes, actually free. Oracle's free tier Arm instances are genuinely usable for real workloads, though you do trade x86 compatibility for Arm builds. For my use case (mostly Node.js and Rust containers), the performance is excellent.

The Architecture

The Oracle VM doesn't run a full Kubernetes cluster. It runs a kubelet as a self-managed node. The control plane is managed by CloudFleet in their free tier. The VM just executes workloads; CloudFleet handles the API server, etcd, scheduler, and all the control-plane heavy lifting.

This gives me a hybrid setup:

Component	Provider	Role
Control Plane	CloudFleet (managed, free tier)	API server, etcd, scheduler
Worker Node	Oracle Cloud Ampere A1 (self-managed)	Runs CI pods via kubelet
GitOps	Flux CD (self-managed)	Reconciles manifests via HelmRelease resources

┌─────────────────────────────────────────┐
│           CloudFleet (Free Tier)        │
│  ┌─────────────┐  ┌─────────────────┐   │
│  │  API Server │  │  etcd/Scheduler │   │
│  └──────┬──────┘  └─────────────────┘   │
└─────────┼───────────────────────────────┘
          │ Tailscale mesh
          ▼
┌─────────────────────────────────────────┐
│      Oracle Cloud Ampere A1             │
│  ┌─────────────────────────────────┐    │
│  │         kubelet                 │    │
│  │  ┌─────────┐    ┌────────────┐  │    │
│  │  │ ARC     │    │ Runner Pods│  │    │
│  │  │ Controller│   │ (dind)     │  │    │
│  │  └─────────┘    └────────────┘  │    │
│  └─────────────────────────────────┘    │
│         Ubuntu LTS                      │
└─────────────────────────────────────────┘
          │
          ▼
┌─────────────────────────────────────────┐
│         GitHub (Actions Jobs)           │
└─────────────────────────────────────────┘

Why This Model?

CloudFleet abstracts away control-plane operations. I get a managed Kubernetes experience without paying for a managed control plane. The Oracle VM provides the compute, CloudFleet provides the orchestration. If the VM dies, I reprovision the node; if the control plane has issues, CloudFleet handles it.

The Runner Meta Chart: Managing Multiple Repos

The official ARC Helm chart deploys one AutoscalingRunnerSet per repository. Maintaining separate HelmRelease manifests for each repository is tedious and error-prone.

I wrote a small custom Helm chart (gha-runner-scale-set-meta) that generates ARC scale sets from a simple repo list. Unspecified values fall back to sensible defaults (minRunners: 0, maxRunners: 3):

repos:
  - name: web-frontend
  - name: api-service
  - name: cli-tool
  - name: docs-site
    minRunners: 0
    maxRunners: 1
  - name: integration-tests
    minRunners: 0
    maxRunners: 2
  - name: terraform-modules
    minRunners: 0
    maxRunners: 1
  - name: container-images
    minRunners: 0
    maxRunners: 1
  - name: shared-libs
    minRunners: 0
    maxRunners: 1

The chart template loops over this list and emits one HelmRelease per repo. Here is a simplified version of the template:

# templates/helmreleases.yaml
{{- range .Values.repos }}
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: {{ .name }}-runner
  namespace: arc-runners
spec:
  interval: 10m
  chart:
    spec:
      chart: gha-runner-scale-set
      version: "0.9.0"
      sourceRef:
        kind: HelmRepository
        name: actions-runner-controller
        namespace: flux-system
  values:
    githubConfigUrl: "https://github.com/your-org/{{ .name }}"
    minRunners: {{ .minRunners | default 0 }}
    maxRunners: {{ .maxRunners | default 3 }}
    runnerGroup: "default"
    containerMode:
      type: dind
    template:
      spec:
        containers:
          - name: runner
            image: ghcr.io/actions/actions-runner:latest
            resources:
              limits:
                cpu: "2"
                memory: "3Gi"
{{- end }}

This template is intentionally simple but designed to grow with your needs. The githubConfigUrl can be parameterized to support different users or organizations, not just a single hardcoded owner. You can also expand the values schema to expose per-repo runnerGroup assignments, custom resource requests and limits, or even machine-shape annotations for workload-aware scheduling. The meta chart starts as a thin wrapper, but it can evolve into a full configuration layer as your requirements get more specific.

Each generated release points at the official gha-runner-scale-set chart with consistent configuration:

Docker-in-Docker (dind) mode for true container builds
Resource limits: 2 CPU / 3Gi RAM per runner (fits ~2 concurrent runners on the 4c/24GB node)
Scale to zero: minRunners: 0 means idle repos spawn no runner pods, so they consume no extra compute beyond the baseline node

Why individual repo runners? ARC supports organization-level runners, which would let you manage a single runner pool for every repo in an organization. The catch: organization-level runners on private repos require a paid GitHub plan. Since most of my repos are private and the whole point of this setup is to avoid recurring costs, paying GitHub for runner access would defeat the purpose. Individual repo runners let me stay on the free plan while still getting self-hosted CI across all repositories. The meta chart is the compromise: a little more YAML, zero subscription fees.

Resource Math

With 4 Arm cores and 24GB RAM, the sizing works out cleanly. The node comfortably handles 2 concurrent standard runners with headroom for system components:

Component	CPU	RAM	Notes
ARC controller + listeners	~500m	~256Mi	Lightweight control plane
Standard runner (×2)	2 each	3Gi each	Concurrent job limit
System overhead	~1 core	~2Gi	kubelet, Ubuntu, monitoring

For bursty workloads, maxRunners: 5 queues additional jobs until capacity frees up.

GitOps Everything

All manifests are managed by Flux CD. The CI namespace reconciles via a GitRepository source and Kustomization resources.

The Flux configuration is straightforward:

# flux-system/github-actions.yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: github-actions
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/your-org/infra-repo
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: github-actions
  namespace: flux-system
spec:
  interval: 10m
  path: ./path/to/manifests
  prune: true
  sourceRef:
    kind: GitRepository
    name: github-actions

Changes to runner configuration follow the standard GitOps flow:

Edit the meta chart values or repo list
Commit and push
Flux detects the change within 1 minute
ARC controller creates/updates/deletes runner scale sets automatically

No kubectl apply, no drift, no "works on my machine."

What Works Well

Zero-cost compute: The Oracle free tier is genuinely usable for this workload
Scale-to-zero: Repos with infrequent activity consume no resources
Meta chart: Adding a new repo is one line of YAML
Flux + ARC: GitOps-native runner management with automatic updates
Renovate on self-hosted runners: Dependency updates (including the ARC chart itself) run daily on this same fleet, using itself as the execution environment
Arm performance: Node.js and Rust builds are surprisingly fast on Ampere

What's Tricky

Arm compatibility: Not all images have Arm variants. I maintain a few custom runners with pre-installed tools.
Single node: No high availability. If the OCI instance goes down, CI stops until it recovers.
Disk pressure: 150GB fills up fast with Docker layers and build cache. Automated cleanup is essential.
GitHub API limits: ARC polls GitHub for jobs. With many repos, you can hit rate limits; the meta chart helps by centralizing configuration but doesn't reduce API calls.

The Migration Reality Check

I already had a free tier Oracle instance running when I decided to add it to CloudFleet. It hosted Uptime Kuma, Cloudflare Tunnel, and Tailscale. I used it as a reverse proxy for various services. The plan was simple: reuse the existing machine, install the CloudFleet agent, and start scheduling CI workloads alongside my existing services.

It did not work. CloudFleet apparently runs its own Tailscale mesh internally for node connectivity and management. My existing Tailscale installation conflicted with theirs. Rather than debug the networking overlap, I decided to separate concerns completely.

I migrated the existing services off the machine, destroyed the original instance, and provisioned a fresh Oracle VM dedicated solely to CloudFleet workloads. CloudFleet connected cleanly to the new machine and began scheduling pods immediately.

The lesson: if you already run networking overlays or VPNs on a machine you want to add to CloudFleet, expect conflicts. It is cleaner to start fresh with a dedicated node.

This also reinforced that this is a self-managed node. CloudFleet handles the Kubernetes control plane and scheduling, but I am still responsible for the VM itself. OS updates, security patches, and disk cleanup are on me. The node does not manage itself.

Security on Self-Hosted Runners

Self-hosting CI shifts the security model entirely onto you. GitHub-hosted runners are ephemeral, isolated, and discarded after each job. Your infrastructure is none of those things by default.

The Privilege Problem

ARC lets you replicate the official GitHub-hosted runner environment closely, including the ability to run privileged containers and access host resources. This is powerful for Docker-in-Docker builds, but it is also dangerous. A compromised runner with privileged: true can escape its container, access the host node, and potentially pivot to other namespaces or connected repositories. Do not mount host paths or secrets into runner pods unless absolutely necessary.

Containment and Trust Boundaries

Even within the same CloudFleet-managed cluster, CI workloads run in dedicated namespaces (arc-systems, arc-runners) with network policies and RBAC restrictions. CI workloads are inherently untrusted: they execute arbitrary code from pull requests, and a malicious or compromised dependency can exfiltrate secrets, modify source code, or attack the build environment. On self-hosted runners, that attack surface includes your node and potentially your cluster.

Namespace isolation helps contain the blast radius, but it is not a guarantee. I layer several mitigations on top:

Network policies blocking egress from runner pods to internal services
No persistent volumes mounted into runner pods
Regular node rotation via VM recreation
Separate GitHub tokens with minimal scope for ARC registration
RBAC restrictions and the principle of least privilege

Scaling Beyond the Free Tier

The Oracle free tier handles my current workload, but it is a single point of failure. When the time comes to scale, CloudFleet supports attaching nodes from multiple cloud providers to the same cluster. You can add Hetzner Cloud or EC2 instances as additional worker nodes without changing your GitOps configuration. CloudFleet handles the lifecycle of these machines, creating and deleting them as needed.

CloudFleet organizes additional capacity into fleets (similar to scaling groups), which define the maximum compute capacity you want available. Nodes within a fleet can have different machine shapes, from a budget CX23 (2 vCPU, 4GB RAM) to a larger CX33 (4 vCPU, 8GB RAM) or dedicated CPU instances. The fleet acts as a ceiling on total compute, not a uniform node pool. This means you can go from a single free Oracle node to a multi-cloud, multi-node CI fleet without changing your manifests. The cluster simply gains more capacity to schedule pods.

Note that CloudFleet's free tier caps total compute at 24 vCPU. The Oracle Ampere A1 instance already consumes 4 of those, leaving 20 vCPU of headroom within the free tier before you need to upgrade.

The Cost Math: GitHub Actions vs. Hetzner

Right now, the entire CI fleet runs on a single free Oracle node. The question is: when does it make financial sense to add paid capacity?

Compare a Hetzner CX33 (4 vCPU, 8GB, ~$7.99/month after the April 2026 price increase) to a GitHub-hosted Linux 2-core runner at $0.36/hour. The break-even is roughly 22 hours of CI per month. If your repos burn through the included 2,000 GitHub minutes (33 hours) and you need more runtime, a Hetzner node becomes cheaper.

And unlike GitHub's per-minute billing, the Hetzner node is yours 24/7. You can run multiple concurrent jobs, keep build caches warm, and schedule Renovate or other automation without worrying about metered costs.

One catch: Hetzner bills in full-hour increments. If you spin up a machine for 10 minutes, you pay for the full hour. For cost effectiveness, you should recycle machines rather than spin up fresh ones for short jobs. This makes Hetzner ideal for a persistent runner pool (like ARC's scale sets) rather than truly ephemeral per-job instances.

Workload-Aware Scheduling

CloudFleet doesn't just add generic capacity. You can annotate workloads to request specific machine shapes. A lightweight microservice might get a CX23, while a heavy integration test suite gets a CX33 or dedicated CPU instance. If you don't specify an annotation, CloudFleet falls back to your resource requests and limits to pick an appropriate shape. If neither is provided, it chooses the cheapest option. This means you don't have to manually manage node pools or taints. Just declare what you need, and CloudFleet provisions the right hardware.

The Hybrid Workload Split

The real architectural win is splitting persistent baseline services from bursty CI workloads. The Oracle node runs 24/7 and hosts the always-on infrastructure:

ARC controller and listeners (must poll GitHub continuously for job events)
Test databases and caches (PostgreSQL, Redis, or MinIO for integration tests)
Build artifact caches (sccache or registry proxies to speed up repeat builds)
Flux CD and monitoring (the GitOps agents and lightweight Prometheus stack)

These are lightweight, persistent services that cost nothing extra on the Oracle node but would burn through metered GitHub minutes if they ran on hosted runners.

When a heavy CI job fires (e.g., a full Rust release build, Docker image compilation, or parallel test matrix), CloudFleet can spin up Hetzner nodes to handle the burst. The job schedules on the fresh capacity, runs, and the node can be recycled. You get a free baseline with elastic burst capacity, rather than paying for compute that sits idle 90% of the time.

The Single Node Risk

The Oracle free tier is genuinely free, but it's a single node. If it goes down, your persistent services and baseline CI capacity disappear. Adding a paid Hetzner node pool to the same CloudFleet cluster provides redundancy and scaling without giving up the free Oracle node. The cluster can tolerate losing either provider and still schedule workloads. This is the difference between a toy homelab and a production-ready setup.

The Config

If you want to replicate this setup, the key Flux CD and ARC resources are:

Flux HelmRelease docs: https://fluxcd.io/flux/components/helm/helmreleases/
ARC Helm chart: https://github.com/actions/actions-runner-controller/tree/master/charts
ARC documentation: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller
Meta chart pattern: A wrapper Helm chart that loops over a repo list and generates individual HelmRelease resources for each repository

Conclusion

Self-hosting CI doesn't have to mean babysitting Jenkins. With GitHub ARC, Flux CD, and a small custom chart, I get elastic, GitOps-managed runners on free hardware.

If you're running Oracle's free tier and want CI that scales to zero, this pattern works.

Hardware: Oracle Cloud Ampere A1 (4c/24GB/150GB) | Control Plane: CloudFleet (free tier) | OS: Ubuntu LTS | GitOps: Flux CD | CI: GitHub Actions (ARC)

Robust Scripts in Azure Pipelines

Fri, 19 Jul 2024 00:00:00 GMT

When developing software, CI/CD pipelines are often used to unit test the code, perform static analysis, deploy artifacts to staging environments, or roll out features to users. Scripts are frequently used to glue programs together.

How Azure Pipelines Scripts Work

Azure Pipelines, part of the Azure DevOps suite of tools, is a cloud-based service that automates the building, testing, and deployment of code projects. It supports continuous integration (CI) and continuous delivery (CD), allowing developers to automate their workflows efficiently. Azure Pipelines can run scripts using different interpreters depending on the platform. For this article, we focus on bash as used for the Linux (Ubuntu) and macOS runners.

A typical Azure Pipeline defined in YAML might look like this:

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: |
    echo "Hello, World!"
    cp ./somefile somewhere
    cat somewhere/somefile | grep things
  displayName: 'Run custom script'

In this example, the script step runs a simple illustrative bash script on an Ubuntu agent. Azure Pipelines supports various properties for scripts, such as setting the working directory, environment variables, and handling errors. This is not dissimilar to other CI/CD environments and providers, such as GitLab CI/CD and GitHub Actions.

Behind the scenes, the script step creates a bash script with the script contents and executes them. Each line in the script is executed individually and in succession, meaning that exit codes are not checked by default.

Even when these script blocks are only used as glue, it can be quite challenging to debug, when a build fails or the pipeline in general fails. I noticed, personally, that errors were not caught early on but silently ignored, only to creep up later in a build and lead to errors. This can be the case, for example, when zipping files and extracting or deploying them later on. What happens if a file is missing, an environment variable is not set?

Unofficial Bash Strict Mode

Using the unofficial bash strict mode in your scripts within Azure Pipelines, or really any script, can significantly enhance the robustness and reliability of your automation processes.

But what is the unofficial bash strict mode?

set -euxo pipefail
IFS=$'\n\t'

Unofficial bash strict mode in two lines

Here's a breakdown of what each of these settings does:

set -e: This option causes the script to exit immediately if any command exits with a non-zero status. This prevents the script from continuing to execute commands after an error has occurred, which could lead to unexpected behaviour or further errors. Keep in mind that simple operations like variable++ might not have an exit code of 0 and stop execution of your script.
set -u: This option treats unset variables as an error and exits immediately. This helps catch typos and other mistakes where a variable is referenced before being set.
set -x: Print each command and its arguments to standard error as they are executed, which helps in debugging. Keep in mind that combined with the azure pipelines flag to exit on stderr, this might lead to false positives in error detection in your pipeline. It might also spam your logs with more information than you expected when looping in your script.
set -o pipefail: This option ensures that the return value of a pipeline is the status of the last command to exit with a non-zero status, or zero if no command exited with a non-zero status. This prevents errors in a pipeline from being masked.
IFS=$'\n\t': This sets the Internal Field Separator (IFS) to newline and tab only, which helps avoid issues with word splitting on spaces. The default IFS includes space, tab, and newline, which can lead to unexpected splitting of strings. Keep in mind that you don't need this flag if you never split strings. If you do, have a look at your data and figure out the best field separators for you.

Always remember that you can choose any of the switches to set in combination. You can leave out parts that might cause more trouble than they might help. Don't blindly copy the two lines into your pipelines and scripts, but understand the implications of them. For general usage, the two lines above are still a good fit and prevent most errors.

Combining Unofficial Bash Strict Mode with Azure Pipelines

To integrate the unofficial bash strict mode into your Azure Pipelines scripts, you can include the necessary settings at the beginning of your bash scripts. Here's an example of how to do this:

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: |
    set -euxo pipefail
    IFS=$'\n\t'

    # Your script commands here
    echo "Running in strict mode"
  displayName: 'Run script with unofficial bash strict mode'

Reference the Script in Your Azure Pipeline YAML

That's all Folks!

Integrating the unofficial bash strict mode into your Azure Pipelines scripts can lead to more robust, reliable, and maintainable automation. By ensuring that errors are caught early and providing detailed debugging information, you can streamline your CI/CD processes and reduce the likelihood of subtle bugs causing issues in your deployments.

As always, it is worth understanding what each of the toggles and knobs do and choosing what you want to implement and why. The unofficial bash strict mode isn't a wonder weapon, but a nice little toolset from which you can pick from.

Leveraging Tailscale Docker Mod - Simplified Networking and Secure Application Hosting

Tue, 01 Aug 2023 00:00:00 GMT

Combining the ease of Docker with the security of Tailscale in a universal docker mod offers exciting possibilities. This blog post explores how the Tailscale Docker mod enables effortless access to remote applications while maintaining robust security measures.

Docker has revolutionized the way we deploy applications, making containerization an essential part of modern software development, and Tailscale has emerged as a powerful tool for creating secure networks and establishing encrypted connections between devices.

I've been considering adding more Tailscale nodes to my network for a while now. I had been running a few self-hosted applications behind Cloudflare tunnels, but I wasn't satisfied with the outcome. Even though traffic was securely being tunnelled through Cloudflare, my apps were still accessible from the open internet. It would be ideal to only expose the parts of the network that should be public, like a website or service that you host for others. What are your thoughts on using Tailscale to connect to your apps instead?

What is the Tailscale Docker Mod?

The Tailscale Docker mod is a universal modification for images provided by linuxserver.io, a community of image maintainers and a popular repository for Docker images. By incorporating this mod into a container, you can harness the capabilities of Tailscale within your dockerized applications. The mod automatically installs the Tailscale daemon into the container and manages its lifecycle. The container is then accessible as a node on your Tailnet. This can, for example, allow multiple containers, running on different servers or virtual machines, to seamlessly communicate over a secure WireGuard tunnel without the need for manual network management. Another use case would be to only allow specific Tailscale users to connect to the node using ACLs. This improves the security of the application, since the application is only accessible by a limited number of people over this specific connection. Thus, you get an additional factor of security, even before a user can log into an application.

Simplified Network Communication

Let's illustrate the advantages of the Tailscale Docker mod with an example. Imagine you have two servers – one hosting a database and the other running an application. By implementing the Tailscale Docker mod in both containers, you can establish a secure and encrypted connection between these servers using WireGuard. This means that the database server can securely transfer data to the application server over the tailnet, with minimal configuration required.

Anywhere Access via your Tailscale tailnet

The Tailscale Docker mod introduces the concept of the tailnet, which refers to the network spanned by Tailscale hosts. This network ensures that all containers running the mod, as well as users' machines and other servers running the tailscale daemon, can communicate with each other, irrespective of their physical locations. Therefore, regardless of whether your servers are in the same data center or spread across the globe, they can seamlessly exchange information through the secure Tailscale tunnel.

TLS Certificates and Tailscale Serve

One of the noteworthy benefits of combining Tailscale with Docker is the use of Tailscale serve, a reverse proxy built into the daemon that will be running on all machines. This feature allows you to serve applications with a Let's Encrypt TLS certificate effortlessly. With tailscaled handling the certificate management, you can focus on other things without the hassle of manual certificate generation or setting up an acme client yourself. Since many dockerized applications expect to be reverse proxied anyway and don't expect to handle TLS themselves any more, this worked seamlessly in my tests. Gitea, nextcloud et al. run great behind Tailscale.

Secure Self-Hosting Made Simple

Tailscale Docker mod offers a fantastic solution for self-hosting applications, granting access only to specific users, teams, or family members. By leveraging Tailscale's end-to-end encryption, you can ensure that your applications remain accessible only to the people you specifically chose. Users accessing the application through a browser won't be aware of the underlying Tailscale encryption. Keep in mind, though, that the encryption provided by Tailscale itself, namely the WireGuard VPN which is the base of the network, merely acts as another layer of encryption. I still recommend that you host the application over TLS in addition to guard against a wide variety of attacks.

Taking it a Step Further with Tailscale Funnel

I know, I know, sometime you want to share an app with a wider audience. For those seeking to make their applications accessible to the broader internet, tailscale funnel comes into play. Tailscale funnel enables you to make your applications reachable on the internet through a subdomain under a vanity URL. Though the solution is convenient and secure, it has one limitation compared to using cloudflared and the Cloudflare dashboard. With Tailscale funnel, you can only pick a subdomain under a few options, e.g., myapp.vanity-url.ts.net or otherapp.awesome-sauce.ts.net, whereas Cloudflare allows you to host applications under a domain name that you control fully. Another upside is, of course, that you do not need to buy a domain, the subdomain comes for free with MagicDNS and Tailscale. Tailscale also does not offer SSO integration for the applications. You will still need to set this up in another way if you need it.

Useful for development

With Tailscale you can mimic a powerful feature that you get for example for Cloudflare pages or from other integrated hosting platforms: Ephemeral testing sites. With Tailscale, you can host a container publicly or privately for a short amount of time to test out features or check out the result of a pull request. The following two files are part of an example static single page application and how it will be started with compose.

# syntax=docker/dockerfile:1
FROM node:18 AS build


COPY . /app
WORKDIR /app
RUN <<EOF
    npm ci
    npm run build
EOF

FROM lscr.io/linuxserver/nginx:latest AS host
COPY --from=build /app/dist /config/www

version: '3.7'
services:
  app:
    build: .
    environment:
      - TAILSCALE_AUTHKEY=tskey-auth-you-thought-i-would-give-you-a-key-l0l
      - TAILSCALE_USE_SSH=0
      - TAILSCALE_STATE_DIR=/var/lib/tailscale
      - TAILSCALE_SERVE_PORT=80
      - TAILSCALE_SERVE_MODE=https
      - TAILSCALE_HOSTNAME=${RANDOM_HOST_NAME}
      - DOCKER_MODS=ghcr.io/tailscale-dev/docker-mod:main
    volumes:
      - tailscale:/var/lib/tailscale
volumes:
  tailscale:

Since our hosting image is based on linuxserver's nginx image, we can simply add the Tailscale mod and provide the environment variables to plumb it into our Tailnet. Using, for example, environment variables and a random name generator, you could then conceivably copy the aforementioned feature of ephemerally hosted websites.

Conclusion

In conclusion, the Tailscale Docker mod provides a seamless way to integrate the benefits of Docker and Tailscale, offering simplified networking and secure application hosting for your containers. By effortlessly creating secure WireGuard tunnels and utilizing Tailscale Serve for TLS certificates, you can enhance the privacy and security of your applications while maintaining ease of access for authorized users. While Tailscale Funnel opens up the possibility of making your applications accessible to the internet, it comes with certain domain limitations. Nonetheless, the Tailscale Docker mod remains an excellent choice for developers and system administrators looking to streamline network management and bolster their application security.