i'm a software engineer based in the philippines, driven by curiosity and whatever i find interesting. i learn fast with the caveat of goldfish memory (which i call my context lol) and i'm usually self-motivated that i forget to eat.
this is not like other portfolios. feel free to have a look around and explore what makes me, me.
drag empty cork to move around.
drag notes to rearrange them.
use +/− or pinch-wheel to zoom.
click any note to open it.
@schmayterling
open githubrecruiter?
(follow the red line) →the same circle, over and over.
for those who want something simpler
enter simple mode
i enjoy writing code.
if ai solves every problem,
what's left?892 commits. the personal AI agent i've been trying to build since 2023 is finally becoming something i'm proud of.
one question usually turns into three projects and too many open tabs.
typescript, python, rust, go, infrastructure, and agents.
in roughly five weeks
an earlier role handled 2,000+ requests a day at 99.3% uptime.
i update this board whenever my attention changes, so it never settles into a final form.
how WFDs work, when to write one, the states a document can be in, frontmatter format, and the markdown features available.
my desktop is scattered screenshots, dozens of windows, half-finished checklists, and constant switching.
whatever feels urgent or interesting gets the whole pile.
right now, only this website and my ai work count as current.
did i mention this board evolves over time? you might find new stuff here next time. suggestions? email me.
hey@ryanaque.com
i turned weeks of neuroscience papers into her memory system.
weave gives long-running agents memory, state tracking, and retrieval that can be inspected.
i watched a kdrama about a girl who forgets everything every morning and realized my AI agent has the same condition. so i built it a brain.
someone else is
on the other end.
i'm less interested in whether it's good.
ideally when something is coming up, whether it's work related or it's just a personal project of mine i usually let it run at the end because i need pressure to perform things.
diffusion models
i built an AI agent with persistent memory. now i need to figure out if it's remembering the truth or just what i wanted to hear.
AI makes me faster. It also might be making me dumber. I'm figuring out where the line is.
“bro what happened to claude code”
— johnislarry“ah sarado”
— lxsmnsycwhat i learned serving two different sites from one Next.js codebase using middleware hostname detection, rewrites, and a Caddy dev proxy.
tailscale's free tier is generous but i'd rather own the control plane. headscale is the self-hosted replacement and it runs fine on proxmox.
atlas maps symbols, calls, tests, and history so developers and agents can ask structural questions about a repository.
2,239-trial benchmark across 8 OSS repos: Atlas beats a text-search baseline by +0.223 deterministic, +0.127 LLM-judge, at 42% fewer tokens.
orchestrator lets a local model read and control a live chromium page through the devtools protocol.
opening note
wfd / Feb 28, 2026 / 5 min
Stub i haven't finished writing this yet. i publish drafts early as part of WFD 17.
i used Tailscale to access my homelab. Proxmox box, k3s cluster on top, a few services (WFD 15 covers the stack). install the client, authenticate, everything gets a stable IP, MagicDNS gives names. painless.
i didn't have a strong reason to replace it. the free tier covers 100 devices and 3 users which is more than i'll ever need. the control plane still knows every device on my network though, their IPs, their keys, and which subnets they can reach. i already had a box that could run this myself, so i did.
Headscale is a self-hosted, open source implementation of the Tailscale control plane. 35.9k stars, BSD-3 license, v0.28.0 as of Feb 2026. one of the maintainers works at Tailscale and is allowed to work on Headscale during business hours, which is about as close to an endorsement as you'll get from an upstream vendor for an alternative implementation.
Tailscale has two parts: the client (open source, runs on your devices) and the control plane (proprietary, hosted by Tailscale). the control plane handles key exchange, peer discovery, NAT traversal, DNS, and ACL enforcement. the clients do the WireGuard tunneling peer-to-peer.
Headscale replaces the control plane. the clients stay the same. you point tailscale up --login-server https://headscale.example.com at your instance and everything else works.
graph TD
TC["Tailscale control plane (hosted by Tailscale Inc)"] --- T1[macbook]
TC --- T2[phone]
TC --- T3[pixie]
T1 ---|WireGuard peer-to-peer| T2
T1 ---|WireGuard peer-to-peer| T3
T2 ---|WireGuard peer-to-peer| T3
graph TD
HC["Headscale (self-hosted on pixie)"] --- H1[macbook]
HC --- H2[phone]
HC --- H3[aurora]
H1 ---|WireGuard peer-to-peer| H2
H1 ---|WireGuard peer-to-peer| H3
H2 ---|WireGuard peer-to-peer| H3
traffic goes peer-to-peer between clients. the control plane only handles discovery. if NAT traversal fails, traffic routes through DERP relays (Headscale can embed its own).
DERP (Designated Encrypted Relay for Packets) is Tailscale's fallback relay. when two devices can't punch through NAT directly, traffic gets encrypted end-to-end and bounced through a DERP server. the relay can't read anything, it just forwards bytes. Headscale can run its own DERP server or use Tailscale's public ones.
what i used from Tailscale and whether Headscale covers it:
| feature | Headscale |
|---|---|
| MagicDNS | yes, split DNS and extra records |
| subnet routers | yes, with auto-approvers in ACL policy |
| exit nodes | yes |
| ACLs | yes, full Tailscale ACL engine with autogroups |
| OIDC (Google login) | yes, OIDC groups can't be used in ACLs though |
| Taildrop (file sharing) | yes |
| Tailscale SSH | yes |
| embedded DERP server | yes |
| Funnel / Serve | no, i use Cloudflare Tunnel for this anyway |
| network flow logs | no |
| multiple tailnets | no, single tailnet by design |
none of the missing stuff matters for a homelab.
it needs to be reachable for devices to find each other. if it lives inside the homelab and Proxmox goes down, nothing can reconnect. a $5 VPS would fix that, and i only have one site, so if Proxmox is down i can't reach anything regardless. LXC container on Proxmox it is.
Headscale is a single Go binary with no kernel dependencies, so a Debian LXC with 128MB RAM runs it fine.
wget https://github.com/juanfont/headscale/releases/download/v0.28.0/headscale_0.28.0_linux_amd64.deb
dpkg -i headscale_0.28.0_linux_amd64.deb
systemctl enable --now headscale
config at /etc/headscale/config.yaml:
server_url: https://headscale.pixie.local
listen_addr: 0.0.0.0:8080
noise:
private_key_path: /var/lib/headscale/noise_private.key
prefixes:
v4: 100.64.0.0/10
allocation: sequential
dns:
base_domain: tail.home
magic_dns: true
nameservers:
global:
- 1.1.1.1
extra_records:
- name: "grafana.tail.home"
type: "A"
value: "100.64.0.3"
- name: "pixie.tail.home"
type: "A"
value: "100.64.0.1"
database:
type: sqlite
sqlite:
path: /var/lib/headscale/db.sqlite
100.64.0.0/10is the CGNAT range that Tailscale reserves for device IPs. it won't collide with your LAN. every device on the mesh gets a stable100.x.x.xaddress.
Headscale recommends SQLite over PostgreSQL. from the config comments: "All new development, testing and optimisations are done with SQLite in mind."
i already had a Caddy LXC handling TLS for other services so that sits in front.
pod CIDR is 10.42.0.0/16, service CIDR is 10.43.0.0/16. the same cluster running the stuff from WFD 13 and WFD 21. to reach pods and services from my laptop over the mesh, one of the k3s nodes advertises those subnets as routes.
subnet routing lets a node on the mesh act as a gateway to a local network. aurora advertises the k3s pod and service CIDRs, so any device on the tailnet can reach cluster IPs without being inside the cluster itself. the traffic goes laptop → aurora (via WireGuard) → k3s network.
# may@aurora
sudo tailscale up --login-server https://headscale.pixie.local \
--advertise-routes=10.42.0.0/16,10.43.0.0/16
approve the routes:
headscale routes list
headscale routes enable -r <route-id>
or set up auto-approval in the ACL policy:
{
"tagOwners": {
"tag:k8s": ["may@"]
},
"autoApprovers": {
"routes": {
"10.42.0.0/16": ["tag:k8s"],
"10.43.0.0/16": ["tag:k8s"]
}
},
"acls": [
{ "action": "accept", "src": ["*"], "dst": ["*:*"] }
]
}
after this, kubectl works from my laptop without port forwarding or a VPN gateway and any device on the mesh can hit k8s services by cluster IP.
there's a Terraform provider: awlsring/headscale. v0.5.0 supports Headscale v0.28.x.
terraform {
required_providers {
headscale = {
source = "awlsring/headscale"
version = "0.5.0"
}
}
}
provider "headscale" {
api_key = var.headscale_api_key
endpoint = "https://headscale.pixie.local"
}
resource "headscale_user" "may" {
name = "may"
}
resource "headscale_pre_auth_key" "k8s_nodes" {
user = headscale_user.may.name
reusable = true
ephemeral = false
time_to_expire = "8760h"
acl_tags = ["tag:k8s"]
}
the pre-auth key automates node registration. i pass it to cloud-init when provisioning k3s VMs so they join the mesh on boot.
a pre-auth key lets a device register with the control plane without interactive login. cloud-init runs on first boot, calls
tailscale up --authkey <key>, and the VM joins the mesh automatically. combined with thetag:k8sACL tag, the auto-approver kicks in and the subnet routes are approved without manual intervention.
i manage my homelab with OpenTofu and the Proxmox provider already. adding the Headscale provider means users, keys, and ACL policies live alongside the VM definitions. one tofu apply and a node exists, is registered, and has its routes approved. that felt good the first time i ran it.
arguments against:
arguments for:
this XDA article has it right: "most people probably shouldn't" switch. Tailscale's free tier is generous and the managed experience is better. i just wanted to.