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.
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.