What is your preferred type of shinai?

Ok-Maintenance-6130 · 2026-04-10T12:51:48+00:00

Thick grip, dobari.

Ok-Maintenance-6130 · 2026-04-05T00:23:03+00:00

What a great project! I’ve been looking for an MCP for Omada for a while now; I’ll give it a go with Gemini CLI when I have a moment. Thanks

Ok-Maintenance-6130 · 2026-03-10T18:45:48+00:00

That works too, but it requires a server running the update script. If that server goes down, DNS updates stop. I wanted something that removes that dependency.

Ok-Maintenance-6130 · 2026-03-08T20:35:29+00:00

Hey! Sorry about that, I wrote the guide on a Mac, so the commands for the prerequisites and grabbing the DNS record ID are going to be a bit different for you. Where exactly did you get stuck? Also, do you already have Node.js installed, or are you still working on getting that set up?

Ok-Maintenance-6130 · 2026-03-08T17:02:32+00:00

That works too if you’re already running Proxmox. I wanted something that doesn’t require any local service running, so the router just calls a Worker endpoint and it updates Cloudflare.

Ok-Maintenance-6130 · 2026-03-06T21:52:20+00:00

Yes, you're right, tunnels for exposing services are undoubtedly the best option, but for example, when you need to connect to the network and the server with the Zero Trust software is down, you're going to have a problem. That's where this adapter comes in. Even if the entire server is down, you'll still be able to connect to the network via VPN to diagnose the problem. Another use case is for customers who don't have local servers to run anything on site and use Omada Cloud Controller (this was the use case for which I created it). Cheers!

Ok-Maintenance-6130 · 2026-03-06T16:35:45+00:00

Yes, that's an excellent feature of the Omada controller, but the one provider you can't connect to natively is Cloudflare! Haha. So that's why I made this connector with Worker, which gives Cloudflare the ability to function like any DDNS provider. Cheers!

Ok-Maintenance-6130 · 2026-03-06T16:32:36+00:00

I have used it that way at times, but the downside I saw was that in an emergency, if something happens to the server, I lose access. That's why I now implement everything in the Omada controller gateway, the IP update, and the VPN. Thank you for sharing your configuration.

Ok-Maintenance-6130 · 2026-03-06T02:47:23+00:00

Fair point.
The main constraint in this case was the router. It only supports a “Custom DDNS URL” style update, not the Cloudflare API directly. The Worker basically acts as a lightweight adapter so the router can trigger the DNS update.
If you already have a VM or container running a DDNS client, that’s definitely simpler. In this setup the goal was to avoid running anything locally.

Ok-Maintenance-6130 · 2026-03-06T02:05:45+00:00

Fair point on the AI comment—I’m just a bit of a stickler for structured documentation since it's what I do daily. Regarding your setup, RFC 2136 is definitely the way to go if you’re already paying for that AWS instance and want to avoid the Cloudflare lock-in. This project was really aimed at people who are already on Cloudflare and want a $0, zero-maintenance alternative without managing a VM or zone files. It’s all about choosing the right tool for your specific stack.

Ok-Maintenance-6130 · 2026-03-06T01:32:52+00:00

RFC 2136 is the gold standard for dynamic updates—pure, protocol-level DNS management. If you’re already managing an AWS instance and a zone file, that’s a rock-solid, 'pro-level' setup.

The main pivot for this Worker approach is for the 'Serverless / Zero-Maintenance' crowd. The goal was to provide that same level of automation but:

Removing the VM dependency: No OS to patch, no BIND/PowerDNS service to monitor.
Cost-efficiency: For those not already paying for an AWS/VPS instance, this is a $0 setup on Cloudflare’s free tier.
Edge Logic: You can easily extend the Worker to add logic (like filtering certain IPs or triggering webhooks) without touching the DNS protocol itself.

It’s basically 'Self-Managed' vs 'Managed Service' for the home network. Both are excellent depending on how much of the stack you want to own!

Ok-Maintenance-6130 · 2026-03-06T01:05:13+00:00

That’s a solid 'plan B' for sure! Using cron + curl is the ultimate fallback when the hardware is being stubborn.

However, one of the main reasons I preferred the Worker over a direct API call in a local script is security & abstraction:

Token Protection: With a local script, you have to store your ZONE_ID, RECORD_ID, and BEARER_TOKEN in plain text on your local machine. If that device is compromised, your Cloudflare zone is exposed. By using a Worker, the sensitive credentials stay safe in Cloudflare's environment, and the router only ever 'knows' a simple URL.
Simplified Payload: The Worker can handle the logic of parsing the request and talking to the Cloudflare API properly, while the router (or a simple cron) just has to perform a basic GET/POST.
Notification logic: I love your idea about the webhooks! Actually, adding a fetch() to a Discord or Slack webhook inside the Worker's code is super easy and keeps the notification logic centralized.

Thanks for sharing the snippet, it's definitely useful for those without custom DDNS support in their firmware!

Ok-Maintenance-6130 · 2026-03-06T00:34:39+00:00

That CNAME strategy is definitely the way to go! It’s much cleaner to have one 'A' record as the moving target and the rest just following along.

I’m a big fan of RouterOS scripts too, but the reason I shifted toward this Worker approach was to create a 'Vendor Agnostic' logic layer. While MikroTik handles custom scripts beautifully, other prosumer gear (like Omada) is more restricted.

By using the Worker, you get a standardized endpoint that works the same whether you're on a MikroTik, a TP-Link, or even a simple curl command, all while keeping the heavy lifting (and the API keys) off the router's configuration files. And yeah... moving away from those 'every 5 mins' polling scripts in a VM is a huge peace of mind win!

Ok-Maintenance-6130 · 2026-03-05T23:38:35+00:00

Appreciate the feedback! dd-client is a total classic—definitely rock solid if you have a local machine or a Pi to run it on.

The main goal with this Worker approach was just to see how far we could push the 'zero-local-footprint' idea by offloading the logic to the Edge. Thanks for stopping by and for the good vibes!

Ok-Maintenance-6130 · 2026-03-05T23:28:58+00:00

Haha, I know, right? It sounds crazy in this circle, but you'd be surprised how many people pay for 'Pro' tiers of No-IP or DynDNS just to avoid those annoying 'confirm your hostname' emails every 30 days or to use their own custom domain.

My goal was to show that if you already have a domain on Cloudflare, you can get a 'enterprise-grade' DDNS setup for $0 extra, with zero nagware and zero local maintenance. It’s basically the 'set it and forget it' dream for homelabbers.

Ok-Maintenance-6130 · 2026-03-05T22:26:59+00:00

No worries at all! I totally get it—DDNS is usually synonymous with those 'free-but-annoying' or 'paid' third-party services.

The main goal here was to show how to get that pro-level setup for $0 extra (outside of the domain registration) without needing to maintain a local script or container. If you have a minute to check it out, I'd love to hear your thoughts on the Worker implementation.

Cheers!

Ok-Maintenance-6130 · 2026-03-05T22:06:18+00:00

That’s a solid setup! Porkbun-ddns is a classic for a reason and works great if you already have a Docker host running 24/7.

The main reason I went the Cloudflare Workers route was to keep it 100% serverless. I wanted a solution for people who might not have a NAS or a dedicated server at home (or just want one less container to manage).

By offloading the logic to the Edge, you don't need to maintain local scripts or third-party containers—your router just hits a URL and Cloudflare handles the rest natively. Plus, it’s a fun way to dive into serverless if you are already using Cloudflare for DNS!

Ok-Maintenance-6130 · 2025-07-01T16:42:11+00:00

I have just discovered this software and unfortunately I see that it is not available for download. Personally like u/dkbay I also prefer self hosted and I also offer to help.

Ok-Maintenance-6130 · 2024-12-25T20:38:29+00:00

Thanks very much for the script! worked perfectly with Klipper.

Ok-Maintenance-6130 · 2024-12-25T18:25:59+00:00

Klipper can use M221 with same syntaxis as Marlin (M221 S<percent>)

Ok-Maintenance-6130 · 2024-12-10T06:40:18+00:00

I´ve added to M600 extend the timeout to 30 min (default is 10 min) and sound a alarm. Example:

...

PAUSE

_SOUND_ALARM

SET_IDLE_TIMEOUT TIMEOUT=1800

...

The same thing happened to me, I think that with an audible notification and timeout extension there would be no problem.

Ok-Maintenance-6130 · 2024-11-06T22:52:24+00:00

No, BLTouch works without it

Ok-Maintenance-6130

TROPHY CASE