Alright. Here https://github.com/MansoorMajeed/Dubernetes

But Why?

A while ago I wrote about how Kubernetes runs containers under the hood

And this was my "dumb architecture" from that article

So I thought, why don't I vibe code a dumb one? It could be a valuable resource for someone learning container orchestration. I initially thought of writing it by myself, but a quick look at my graveyard of half-baked projects convinced me otherwise.

Requirements - How should it work?

I want to write down a desired state for my app in a yaml file, use a command line tool similar to kubectl and Dubernetes should then use that to create Docker containers to run my application.

The Yaml should be something like this

name: myapp
image: myapp-image:latest
replicas: 3
access:
  host: myapp.local

It is as simple as it can be

• Give a name

• Specify a docker image to run (no sidecars in Dubernetes sorry)

• Specify how many replicas (docker containers)

• Expose it via a domain name (Built-in ingress)

Building it

Step 1 : Deciding on the basics

• Language : When it came to the language, was there ever any doubt? It had to be Go. It’s the native tongue of Kubernetes and is fantastic for building the kind of system-level tools like Dubernetes

• AI Assistant: I decided to go with Claude code

Step 2: Brainstorming with Claude Code

I spent a bit of time talking to Claude about what we are going to build. We discussed about the yaml structure, and the need for keeping everything simple. Initially it suggested a whole lot of complicated features. But added the following lines in CLAUDE.md to curb Claude's enthusiasm a little bit

Design Goals
Maximum Simplicity: One orchestrator, one proxy, minimal components
Learning Focus: Understand orchestration without enterprise complexity

Claude can be opinionated if you don't drive the conversation. So be very vocal about your vision and you will of course be bombarded with the classic You're absolutely right

Take as much time as needed in this step. Make sure to not overload the context with unnecessary information.

Coming up with a high level architecture

After talking to claude for some time, we came up with an architecture.

You can find the detailed architecture here. Here is a high level view of the overall system

• A single binary Orchestrator

  • It has API endpoints where the user can make requests about the desired state of the containers (more on this later)

  • This state is stored in an SQLite database

  • It will have a reconciler component that will run in a loop and make sure that the actual state of the running containers matches the desired state in the database

    • It uses the docker command to manage docker containers on the host machine

• dubectl the command line tool for the user to interact with the API

• An in built Nginx container that act as an ingress to route traffic from outside the "cluster"

Step 3 : Creating an implementation plan

Once the architecture is clear, next step was to have Claude create an implementation plan.

I wanted to make sure that with each change, Claude will not break existing functionality. So I decided to go with Test Driven Development

Building Dubernetes using Test-Driven Development (TDD) approach. Each phase starts with writing tests, then implementing the functionality to make tests pass.

So we wrote down the implementation plan into a markdown file. You can find that HERE

At this point I also made sure to update the CLAUDE.md to reflect these documents and the vision. Check it out HERE

Step 4 : Session Continuity made easy!

After creating a clear direction, I asked claude to use a markdown file PROJECT_STATUS.md to keep the status updated after each session. Exact instruction in CLAUDE.md

**Session Continuity**
Status File: PROJECT_STATUS.md - Contains current progress and context 
Resume Protocol: When starting new sessions, check PROJECT_STATUS.md for:
- Current implementation phase
- Completed tasks and checklist status
- Active development context
- Next steps and priorities
- Key Design Principles

Additionally, this line

When user says "let us wrap up for the day", update PROJECT_STATUS.md with current progress and context for seamless session resumption.

Step 5: Vibe!!

Once the plan was locked in, I stepped back and let Claude handle the implementation.! I did not look at the code, not even once!

Step 6 : Reset often

After finishing a milestone (tests passing – both manual and unit), commit it, have Claude update the PROJECT_STATUS and /reset to free up context! I found that this simple act made Claude very consistent.

While you might think you have ample context window to spare, an LLM's performance actually degrades significantly as the context grows, well before reaching the advertised maximum. There's a sharp drop-off, which this graph illustrates perfectly.

Source: https://research.trychroma.com/context-rot#results

The Code Flow

Step 1 : The Yaml

Let's take the previous example yaml

name: myapp
image: myapp-image:latest
replicas: 3
access:
  host: myapp.local

We want the myapp-image:latest docker container to run with 3 containers and have it respond at the domain myapp.local

Step 2 : Applying it using dubectl

PodSpec looks like this

cmd/dubectl/types.go

type PodSpec struct {
	Name     string      `yaml:"name" json:"name"`
	Image    string      `yaml:"image" json:"image"`
	Replicas int         `yaml:"replicas,omitempty" json:"replicas,omitempty"`
	Access   *AccessSpec `yaml:"access,omitempty" json:"access,omitempty"`
}

The CLI tool Makes an API call

cmd/dubectl/types.go

// CreatePod creates a new pod via the API
func (c *APIClient) CreatePod(podSpec *PodSpec) error {
	// Convert PodSpec to API request format
	requestData := map[string]interface{}{
		"name":     podSpec.Name,
		"image":    podSpec.Image,
		"replicas": podSpec.Replicas,
	}

Step 3 : The Orchestrator API receives the request

pkg/api/handlers.go

Upon receiving the POST request, orchestrator does some validation and calls CreatePod

// createPod handles POST /pods
func (h *Handler) createPod(w http.ResponseWriter, r *http.Request) {

    // ----snip-----

	// Create pod
	pod, err := h.orchestrator.CreatePod(r.Context(), req)
	if err != nil {
		h.writeError(w, http.StatusInternalServerError, "failed to create pod", "CREATE_FAILED", err.Error())
		return
	}
}

cmd/orchestrator/main.go

// CreatePod creates a new pod
// Simply creates a database entry for the pod
func (o *OrchestratorImpl) CreatePod(ctx context.Context, req api.PodRequest) (*api.PodResponse, error) {

    //-----snip-----

	// Convert API request to database pod
	dbPod := &database.Pod{
		Name:         req.Name,
		Image:        req.Image,
		Replicas:     replicas,
		DesiredState: "running",
		CreatedAt:    time.Now(),
		UpdatedAt:    time.Now(),
	}

	err := o.db.CreatePod(dbPod)
	if err != nil {
		return nil, err
	}
    //-----snip-----
}

Step 4 : Reconciler creates containers

pkg/reconciler/reconciler.go

Finally, create the docker container, update Ingress nginx configuration

// ReconcileOnce performs a single reconciliation cycle
func (r *Reconciler) ReconcileOnce() error {
	// Get all pods from database
	// Reconcile each pod
	// Update nginx configuration
}


// reconcileRunningPod ensures a pod has the correct number of running replicas
func (r *Reconciler) reconcileRunningPod(pod *database.Pod, replicas []*database.Replica) error {
	runningReplicas := 0
	var replicasToRestart []*database.Replica

	// Count running replicas and identify failed ones
	// Restart failed replicas
	// Remove excess replicas if needed
    // Create additional replicas if needed
}

func (r *Reconciler) createReplica(pod *database.Pod) error {
	// Allocate port
	// Generate replica ID
	// Create replica record first

	// Create container
	req := &docker.RunContainerRequest{
		Image:  pod.Image,
		Name:   replicaID,
		Port:   port,
		Labels: map[string]string{
			"dubernetes.pod":     pod.Name,
			"dubernetes.replica": replicaID,
		},
	}
	containerID, err := r.docker.RunContainer(req)
}

Running it!

Build and start the orchestrator

make build
./bin/orchestrator &

Run a demo pod

./bin/dubectl apply -f examples/whoami-service.yaml

We can see that the 3 app containers and the nginx (which acts as the ingress) container running

Making a request

We can make a request using curl and the --resolve flag to map the domain whoami.local to 127.0.0.1, letting us send a proper request as if the hostname resolved normally

$ curl localhost  --resolve whoami.local:80:127.0.0.1
Hostname: 53b4ab629c3e
IP: 127.0.0.1
IP: ::1
IP: 172.17.0.3
RemoteAddr: 172.17.0.2:42188
GET / HTTP/1.1
Host: localhost
User-Agent: curl/8.7.1
Accept: */*
Connection: close
X-Forwarded-For: 192.168.65.1
X-Forwarded-Proto: http
X-Real-Ip: 192.168.65.1

okay it works!

Conclusion

It turned out to be surprisingly easy to vibe-code the whole thing without Claude melting down. I think the main reason was sticking to test-driven development and regularly resetting the context. I had a ton of fun and I hope you had a decent read too!

What is this about?

You're at home, and claude-code is busy building your next billion-dollar project. But you've got to run and don't want to lug your laptop with you. The problem? When Claude finishes an item on its to-do list, you need to be there to press a key to let it continue.

What if you could do that from your phone, without paying for anything extra? That's what this post is about.

But why would you do that?

Great question. Before you go any further, you should really ask yourself: do you really want to do this? If you're taking a walk, then take the walk. Don't bring Claude with you.

This guide is for that one time you're out and it would be a massive help to quickly review Claude's work, press 1, 2, or Esc, and then immediately put your phone away. If that's the case, read on.

How does it work?

It's quite simple. We'll enable SSH on your workstation, run claude-code inside tmux (to keep it alive), and connect to your workstation from your phone via an SSH client. To make it all work seamlessly while your phone is on 5G and your laptop is on your home network, we'll use a bit of magic called Tailscale.

Is it free?

Yes (except for claude-code, everything else is free)

Is it safe?

Yes. No one can see your traffic. Take a look at how tailscale works to get an idea, if you are interested. TL;DR is that Tailscale builds a private tunnel between your devices, no traffic flows through Tailscale's servers (it is peer to peer)

Is Tailscale safe? Yes; You can enable Tailnet lock to be extra secure

Is there an easier way?

Maybe. There are tools like VibeTunnel . I have not tried it. I would rather rely on tried and tested solutions like SSH. Feel free to choose whatever works for you.

How to set it up

Step 1 - Enable SSH on your workstation

This of course depends on your operating system.

💡

CAUTION: Enabling SSH on your device means any other device on the same network as you would be able to login to your device if they know your password. Make sure you have a strong password. Ideally, use key based authentication instead of password

MacOS

In MacOS, you can enable SSH by going to settings -> General -> Sharing -> Remote Login. Check Apple docs for more details

It should look something like this once enabled

Linux

Depending on your Linux distro, install and enable SSH server.

• Ubuntu : HERE

• Fedora : HERE

• Arch BTW : HERE

Windows

If you plan to use claude-code with WSL2, you can enable SSH on WSL2 and basically have it work like Linux. Check HERE

Step 1.1 - Disable Password Login (Windows WSL / Linux)

💡

Disabling password based SSH auth on MacOS requires messing with PAM configuration, I have not tried doing so, try it at your own risk.

In your /etc/ssh/sshd_config ensure you have PasswordAuthentication no to prevent password based authentication

Step 2 - Install and setup Tmux

Tmux is a terminal multiplexer – which is a fancy way of saying that you can run a terminal session with any number of tabs/windows on a remote host and detach and attach to it any time.

While not 100% required, Tmux makes it so much more convenient. You can easily switch between your phone and your workstation – continuity is preserved. Additionally, even if you lose internet access on your phone, you can simply reconnect to the Tmux session and resume

Installing Tmux

• Ubuntu sudo apt install tmux

• Fedora sudo dnf install tmux

• Arch BTW sudo pacman -S tmux

Starting Tmux

Open a terminal and simply type

tmux new -s claude-demo

This will create a new tmux session with the name claude-demo

All of tmux commands are done in a funny way. That is, you press Ctrl+b then let go and then immediately press one of the keys. For example

• Ctrl+b, let go completely, press c : Open a new tab

• Ctrl+b, release, press 1 : switch to tab 1

• Ctrl+b, release, d : detach from Tmux. You will be back on your terminal before you started the tmux session. Now, even if you exit or close your terminal, Tmux is still running in the background, waiting for you to re-attach to it

• tmux ls : List Tmux sessions

• tmux a -t claude-demo : Attach again to the running session

Great, now you have a Tmux session running on your workstation

Step 3 - SSH Client for your Phone

Android

There are several SSH client apps available for free. I use Termius. Termux is another option. You can choose whichever you like

iOS

Termius is popular among IOS users too. Or you can find another one you like better

Step 4 - Generating SSH keys for your phone

Depending on the app you use, these steps might vary. You could generate them on your workstation and copy the private keys to your phone's ssh client too. This is fully up to you.

I will show you how to generate ssh keys for your Phone using Termius

• Open Termius

• Go to Vaults -> Keychain -> + button

• Choose New SSH key...

• Choose Generate new SSH key

  • Give it a name you like, it does not matter

  • Type: ED25519

  • Optionally choose a passphrase.

  • Generate

• Click Export or share a public key

Now, you should have your ssh public key available. We need to get this key to your workstation so you can allow this key to access SSH. This public key is completely safe to be shown in public, so you can easily copy it to a note app and transfer it to your workstation

Step 5 - Allowing your phone's SSH key on your workstation

WSL/Linux

Edit or create the file ~/.ssh/authorized_keys and add your public key there

MacOS

Security considerations for MacOS

Enabling public key only SSH on MacOS requires us to edit the pam configuration files. This can mess up things if not done properly. Because of this, the easiest solution is to keep using password for ssh. However this puts us in a risky situation – anyone on the same network could attempt to brute force your password. With that, I recommend you try some or all of the following

• Use a strong password for your Mac user

• Disable remote login (SSH) while you are on insecure wifi networks

• Use MacOS firewall to allow SSH only from the network interface used by Tailscale and drop everything else.

Step 6 - Install Tailscale

For your workstation, go HERE, download and install Tailscale. For your mobile devices, you can download Tailscale from your App store / Play store. Login to both devices using the same account.

Once you have logged in and connected, you should be able to see your devices in the Tailscale admin page.

💡

Note the names of the machines you have -- by default it uses the hostname

Here you can see my devices, helium is the Windows PC I will use this for post. I have WSL2 running on Windows.

Step 7 - Adding SSH host to your mobile device

We are almost there. Let's add SSH connection to your workstation from your mobile device.

Open the SSH client app (Termius in my case)

1. Alias : You can set it to whatever you like

2. Hostname: This should match the Tailscale name (hostname) of your workstation

3. Port : In Linux and MacOS it would be most probably 22, in my case it is 2222 because I am connecting to a WSL2 instance where SSH is configured to run on 2222

4. Username: Replace it with your username for your workstation

5. Password: Leave it empty for Linux and Windows/WSL, enter your password for MacOS

6. For Linux and Windows/WSL, choose the SSH key you created in Step 4

7. Save it

Step 8 - Connecting and Vibing

You are ready to make your billion dollar SaaS.

Re-attach using tmux a -t claude-demo (or create a new session using tmux new -s claude-demo) – You can do this from your phone or workstation, it does not matter

Now that I have Claude-Code running on my PC, I can access it from my phone. Running tmux ls from phone, I can see the claude-demo tmux session

I can attach to it and resume work by simply doing tmux a -t claude-demo

Step 8 - (Optional) Reading and Editing code on your phone

If you want to quickly view some code from your workstation, you can achieve this very easily using code-server, which is a VS code server running on your workstation that can be accessed from your phone's browser

Installing Code Server

Check HERE on how to install this on your operating system.

But TL;DR is running

curl -fsSL https://code-server.dev/install.sh | sh

Running Code Server

Once installed, follow the docs to set it up to start using systemd (if on Linux/WSL2). Otherwise you can manually start it by running code-server on your workstation

When you run it, it will show you the config file code-server will be using, something like /home/your username/.config/code-server/config.yaml

Edit this file

vim /home/mansoor/.config/code-server/config.yaml

And change the bind-addr to 0.0.0.0:8080 so that code-server will listen on all network interfaces (You can change the port number if you would like something else). The same file will also show the password you will use to login to it, take note of it. You

💡

This makes your code-server be accessible over plain text http on your local network. If you use it on insecure wifi networks, you should set up https. Check docs HERE

After changing the bind-addr, restart code-server

Accessing Code Server

From your phone's browser, access your-workstation-hostname:8080