We are also looking to migrate off Cloudflare. I thought Bunny.net was mostly a pure CDN, not a reverse proxy like Cloudflare. Am I wrong? One of the most important things for us would be DDoS protection.
Self Plug-in: We are currently beta testing Hyvor Relay [0], a self-hosted alternative for sending emails. We are focusing more on observability (monitoring DKIM/SPF, periodically querying DNSBLs) and DNS automation.
A simple docker compose up can get a reasonably working setup [1]
We are working on an open-source, self-hosted solution [0] to make this easier. When you correctly set up DKIM, SPF, reverse/forward DNS for IPs, it is not much hard to get emails delivered. IPs can still get blacklisted and you need to monitor blacklists and contact them if it happens. Solutions like Postfix are great, but they lack observability. In our solution, we have developed dashboards and health checks to make it easier to find problems with the set up.
We are currently running beta tests (really appreciate it if you can join).
For the past two months, I have been working on Hyvor Relay [1], an open-source, self-hosted alternative to AWS SES, Mailgun. It's been an awesome ride learning SMTP and DNS in depth. And, we're pretty close to a beta release.
We did this [0] as a 3-devs startup, and it was one of the best things we ever did!
For us, we found ourselves repeating again and again when we had multiple UI projects. It became boring and we decided to write the design system. It took us about 3-4 months to complete this.
- It takes a LOT of effort to migrate old projects. A LOT! So, make sure you really have the time and effort for a migration like that.
- In my opinion, it only makes sense to have a component library if you have multiple different projects / repos.
- Try not to reinvent the wheel. Design your components library, but follow a pattern of a popular library so you can see "hey if you have used this library, it's the same here. Just the UI is different"
- Write an extensive documentation with examples (here's ours: [1])
- In our case, integrating dark mode, docs, and i18n into the design system (in an opinionated way) saved us a lot of time.
Slightly off-topic: Until last week, we used Redis for Laravel queues and cache in our blogging platform. We decided to get rid of Redis and use the database. The reason was that we are planning to allow self-hosting of our software so removing a dependency is a huge win to reduce complexity (didn't know about the license change then). There are a lot of arguments against using a relational DB for queues, but from our testing, it just worked! So, we just went with it in production. Surprisingly, there are no noticeable performance issues so far.
We initially used Redis because, well, Laravel recommends it. But, what I learned is that Redis is not a requirement until you absolutely need it.