Disclosure: I'm building https://proxylity.com, but I'm seeking to understand here, not to promote it.
The fixed cost per region seems like a barrier to experimenters and large development teams alike. It's not much in the grand scheme, but enough to prohibit an individual from standing something up on a whim and leaving it around. Likewise, for large development teams having a stack for every developer would be costly. In each case I'm not talking about "production" workload, but the semi-idle stacks that run for long periods, are critical, need to reflect the production setup, and don't generate revenue.
Your LBs are quick to deploy, which is super important for fluid CI/CD experience but they miss the mark without being usage based.
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
What technique are you using for redirecting traffic to region B when region A is offline? And what happens if I have 2 nodes in a region and one goes offline?
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.
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.
We at DollarDeploy building a platform to deploy apps to your own VPS. For now we just run it on one server, but plan to use DigitalOcean and Hetzner load balancer offering to offer workload scaling beyond one server.
Why did you choose fly.io? The traffic there are very expensive which is an issue for people who would want to run LB.
I love Caddy. Correct me if I am wrong but this looks like a hosted Caddy primarily for Load Balancing ? What about things like SSL termination or general reverse proxy capabilities ?
I would be interested in a hosted caddy cluster that lets me configure everything that Caddy provides without needing to fiddle with Caddyfiles or its API directly.
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.
Maybe a comparison to AWS Global Accelerator would be helpful to understand the "global" aspect. Having instances in multiple regions is just a starting point.
Ahhh got it, this is focusing primarily on load balancing at a lower layer of routing then than what I'm referring to. While not wrong, "global load balancing" threw me off a bit.
EDIT: see the other reply, appears that it handles both given it leverages Fly's Anycast setup.
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.
Get 2 VPS, put your DNS on both (ns1, ns2), use low TTL values, use geolocalization or a rough rule of thumb to have each redirect traffic to the VPS the closest to your client or with the least load
Finally, make each VPS check on the health of the other to stop its DNS pointing to the other VPS: you will already have to have them check on eachother for the load checks.
It's a fun and practical exercise (you may have to write your own DNS servers), after which you can then think on how to do that for more than 2 VPS and the algorithms it entails
I hear you, but I also could write my application in assembly and take 10x as long. If your doing this as a hobby and for fun, sure... But if your trying to launch/scale a company, decisions like this are engineering mode not founder mode.
Before using an existing solution, I like to understand how it works to make sure I will not get bad surprises: being able to reverse and debug using assembly code can be a helpful skill, and likewise for understanding DNS.
Yesterday I vibe code a DNS server from scratch in half a day, because I wanted to test something very specific bridging DNS and mDNS. Doing the same thing for health checks and geo routing may take what, another half day?
The experience and understanding gained can help decide if it's worth using a service like route53 or not, or even better: just doing without the feature, because if you have 1 VPS, "YAGNI" is the likely answer!
If the poster is seriously thinking about scaling to 2 VPS or more, the experience gained will expose the various ways it can fail, to maybe reconsider the decision (maybe instead get beefier hardware?)
In my case, I saw the DNS-mDNS isn't much a problem, so I don't have to reconsider adding the feature I want.
Disclosure: I'm building https://proxylity.com, but I'm seeking to understand here, not to promote it.
The fixed cost per region seems like a barrier to experimenters and large development teams alike. It's not much in the grand scheme, but enough to prohibit an individual from standing something up on a whim and leaving it around. Likewise, for large development teams having a stack for every developer would be costly. In each case I'm not talking about "production" workload, but the semi-idle stacks that run for long periods, are critical, need to reflect the production setup, and don't generate revenue.
Your LBs are quick to deploy, which is super important for fluid CI/CD experience but they miss the mark without being usage based.
Do others see this the same way?
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
What technique are you using for redirecting traffic to region B when region A is offline? And what happens if I have 2 nodes in a region and one goes offline?
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.
We at DollarDeploy building a platform to deploy apps to your own VPS. For now we just run it on one server, but plan to use DigitalOcean and Hetzner load balancer offering to offer workload scaling beyond one server.
Why did you choose fly.io? The traffic there are very expensive which is an issue for people who would want to run LB.
I love Caddy. Correct me if I am wrong but this looks like a hosted Caddy primarily for Load Balancing ? What about things like SSL termination or general reverse proxy capabilities ?
I would be interested in a hosted caddy cluster that lets me configure everything that Caddy provides without needing to fiddle with Caddyfiles or its API directly.
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.
How is "Novnaode" pronounced? How did you come up with this name?
Thanks for sharing your project!
Edit: Ah, thanks @evanjrowley! I'm glad it was a typo, because otherwise the name would have doomed this baby :)
It's a typo. Their website indicates it's Novanode.
Nice catch! Updated the title.
Into the same vein - crude, but truly vendor-independent recipe: https://gist.github.com/Snawoot/b7065addf014d90f858dbd185d51...
This is excellent, but I'm not following how the multi-region deployments work. Is Anycast involved in this somehow?
Maybe a comparison to AWS Global Accelerator would be helpful to understand the "global" aspect. Having instances in multiple regions is just a starting point.
Ahhh got it, this is focusing primarily on load balancing at a lower layer of routing then than what I'm referring to. While not wrong, "global load balancing" threw me off a bit.
EDIT: see the other reply, appears that it handles both given it leverages Fly's Anycast setup.
We're hosted on HN darling, Fly.io. Multi region instances come with a anycast IP
Oh interesting, good to know.
I don't get it. So i have a VPS , then what ?
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.
Get 2 VPS, put your DNS on both (ns1, ns2), use low TTL values, use geolocalization or a rough rule of thumb to have each redirect traffic to the VPS the closest to your client or with the least load
Finally, make each VPS check on the health of the other to stop its DNS pointing to the other VPS: you will already have to have them check on eachother for the load checks.
It's a fun and practical exercise (you may have to write your own DNS servers), after which you can then think on how to do that for more than 2 VPS and the algorithms it entails
Route53 handles this already, health checks, geo routing for pennies. If pointing to AWS services can use alias records.
> Route53 handles this already, health checks, geo routing for pennies. If pointing to AWS services can use alias records.
That would use AWS and insulate you from the details.
The fun part is learning how to do that, which gives you a better idea of how it works and full control of the solution.
You can then think about anycast or getting your own IP blocks
I hear you, but I also could write my application in assembly and take 10x as long. If your doing this as a hobby and for fun, sure... But if your trying to launch/scale a company, decisions like this are engineering mode not founder mode.
That's fair!
Before using an existing solution, I like to understand how it works to make sure I will not get bad surprises: being able to reverse and debug using assembly code can be a helpful skill, and likewise for understanding DNS.
Yesterday I vibe code a DNS server from scratch in half a day, because I wanted to test something very specific bridging DNS and mDNS. Doing the same thing for health checks and geo routing may take what, another half day?
The experience and understanding gained can help decide if it's worth using a service like route53 or not, or even better: just doing without the feature, because if you have 1 VPS, "YAGNI" is the likely answer!
If the poster is seriously thinking about scaling to 2 VPS or more, the experience gained will expose the various ways it can fail, to maybe reconsider the decision (maybe instead get beefier hardware?)
In my case, I saw the DNS-mDNS isn't much a problem, so I don't have to reconsider adding the feature I want.