Hacker News new | past | comments | ask | show | jobs | submit | martianE's comments login

Our product assumes familiarity with Caddy/Nginx -- we'll make it more accessible soon. We give you global anycast nodes on it and you're in full control of the config (they can be edited on the website), so anything you can have in a Caddy config can be used on Novanode.

The managed bits are the certs/configs/failover so that you don't need to be concerned about that.

Though for a single VPS instance it could makes sense to just host your own caddy on that node. If you need global distribution Novanode is a good answer.


We're hosted on HN darling, Fly.io. Multi region instances come with a anycast IP


Oh interesting, good to know.


Yeah, honestly we didn't want to go with the IaaS/cloudflare style pricing model, we give you full fly.io nodes and control of them and forward the cost. Keeps things simple and without the tricks. I can see what you're saying though


Our goal is actually not to hide the configs behind a bunch of partial UI elements you get full control of your proxy. All your caddy configs should work out of the box. For SSL termination we use acme and you can use the dns method (let us know if you dns provider isn't in the plugins and we'll add it)

Pretty much the only thing we add is a storage layer for your certs so you avoid the acme rate limit for multi-region deployments


This addresses questions I had about certificate generation across nodes/regions.

Slightly off topic, but something nice about Caddy is that it automatically falls back on ZeroSSL (if you have an email address defined) when you hit letsencrypt rate limits. I have a case where more certificates for a root domain are needed than LE is capable of providing, and this fallback solves for the rate limit problem seamlessly.


Nice catch! Updated the title.


For high-availability deployments, we leverage Fly.io's global Anycast network and DNS-based health checks. When a machine in region A goes offline, Fly's Anycast routing automatically directs traffic to healthy machines in other regions without manual intervention.

For intra-region redundancy, we deploy 2 nodes per region in HA mode. If one node fails, traffic is seamlessly routed to the other node in the same region through Fly.io's internal load balancing. This provides N+1 redundancy within each region, ensuring service continuity even during single-node failures.


I recommend adding more details like this to the website. Knowing it's Fly.io under the hood gives me significantly more confidence in your service.


Updated the site, we'll add more about it shortly.


How much of a difference would automated health checks+programatic dns updates make vs any cast


Depends on the setup and what your goals are. Anycast typically takes the shortest route based on topology. This is particularly nice when you use something like caddy (because of the huge plugin system, you can do lots of stuff directly on the edge) to build your own CDN by caching at the edge or go all in and use caddy-lua to build apps at the edge. Gluing together dns systems (health checks, proximity + edge nodes) can be similar but the benefits of being "edge" largely go away as soon as you add the extra hop to a different region server.


Try the new bose earbuds. Shits on apple airpods


I cannot stress this enough: write good code! Any decent code editor now jumps you to the source of the code you're calling allowing you to quickly see what the code does, what parameters are needed, etc.

In fact the best documentation I've seen (say flask, django) most of the documentation acts as support for reading the code.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: