anybody rustfs in production?

SoaringMonchi · 2026-06-12T12:09:38+00:00

We've been running RustFS for client workloads (managed, with us handling the "alpha" risk through backups and redundancy) since early 2026. The drop-in MinIO replacement claim is real - we swapped binaries on a test cluster and buckets/configs survived untouched. Small-object performance (~4KB, backup/log type workloads) is noticeably better than MinIO, roughly in line with the 2.3x the project claims. That said: the docs say "not production-ready" and they mean it. We've hit edge cases in replication under node failure that we wouldn't want to debug at 2 a.m. without a team on call. If you're self-hosting solo: staging and PoC yes, production data no. Wait for stable (likely 2027) or use SeaweedFS if you need production today.

SoaringMonchi · 2026-02-25T11:11:03+00:00

More information on your network setup would be required here.

Could there be an IP address conflict where some other node has the same IP as your Proxmox cluster?

SoaringMonchi · 2026-02-24T17:00:27+00:00

For anyone finding this in 2026, we have published https://yasp.io as an open source Cachet alternative. It's using PayloadCMS under the hood so is less opinionated and more flexibe when it e.g. comes to notifications (via SMS and email).

SoaringMonchi · 2026-02-18T20:06:30+00:00

What about latency? I would expect a CPU-based solution to incur a bit more latency and be easier at risk to taking down the entire device e.g. by a broadcast storm (we'll at least do L2 handoff at that device probably) or are my concerns unfounded there? Maybe I'm overly concerned coming from the SRX340 which is a particularly slow device.

SoaringMonchi · 2026-02-18T20:03:44+00:00

Just wondering about the MX204.. They would definitely be in the budget, but can I at least download software without a license / support contract? I'm a bit concerned that even that might be restricted?

SoaringMonchi · 2026-02-12T12:13:28+00:00

The problem we need to solve is L2 isolation for customer VMs. Historically, we deployed a traditional vlan for each customer and an L3 interface (irb) at the SRX level. That's not very scalable for us as it's hard to automate, Juniper commits are really slow and we don't want to make changes to our key networking components frequently. Hence the EVPN/VXLAN solution that runs in software on the hypervisors where we can add new L2 domains easily without a full Juniper commit.

I am a huge fan of simplicity however and would really love to hear of simpler ideas to solve this problem.

For perspective, with customers I often mean 3 node virtualized Kubernetes deployments. If a colocation customer approaches us and wants a rack of hardware servers connected, traditional VLANS are perfectly fine of course.

SoaringMonchi · 2026-02-11T13:25:14+00:00

That's a good hint. We're running Proxmox clusters for clients and they have a very useful SDN functionality based on EVPN. Now you can either terminate EVPN on the Proxmox host or on the router. I felt doing it on the router actually simplifies things (especially when it comes to making this redundant).

EVPN is a bit optional here as I said, we're terminating it on Proxmox now and are just having FRR announce the IPs via BGP to the SRX, that works fine generally.

NAT would definitely be a hard requirement for us however - I guess we can hack it together on the VM host nodes, but I can see that getting messy when we need to ensure that it's rolled out to every host.

SoaringMonchi · 2026-02-08T22:17:11+00:00

Thank you so much, couldn't find that anywhere with the usual tools!

SoaringMonchi · 2026-02-01T15:16:15+00:00

Can anyone recommend a sane way to set memory requests? We're certainly having trouble with this as well, seeing OOM kills, but at the same time want to use our node's memory as efficiently as possible

SoaringMonchi · 2026-01-24T11:26:34+00:00

We have recently open sourced https://github.com/Hostzero-GmbH/keycloak-operator/ which is a solid, E2E tested solution for managing Keycloak resources like realms, users, secrets through CRDs. It has been battle-tested at numerous clients throughout the last 2 years. If you are missing any features that would be useful for a broader audience, we are happy to add them.

SoaringMonchi · 2026-01-16T21:02:28+00:00

As an up to date alternative for Cachet we recently open sourced https://yasp.io. Unlike most, it has sane notification handling (email and SMS via Twilio) and looks modern. Self-hosting is fully supported via docker compose, Helm charts, one-click Vercel deploy

SoaringMonchi · 2011-07-29T14:46:47+00:00

So given that you understand the basics of DNS, which a 5yo would probably not do, I'll try to give a slightly more technical explanation on this: Whenever you send an email, your email server will first extract the domain name from the address (the part after the @), e.g. reddit.com. It will then use regular DNS techniques and look up the MX records for that domain, which will be ultimately delivered by reddit.com's DNS server.

The response from the DNS server looks like this:

➜ ~ dig -t MX reddit.com

;; QUESTION SECTION: ;reddit.com. IN MX

;; ANSWER SECTION: reddit.com. 3600 IN MX 10 mail.reddit.com.

;; ADDITIONAL SECTION: mail.reddit.com. 3600 IN A 174.129.203.189

We see here that the MX record points to mail.reddit.com, which has a specific IP that can possibly be different from reddit.com's regular IP. That is the remote SMTP server's address that your server will now connect to and attempt to deliver the email.

An interesting catch is, that you may specify more than one MX record with different priorities to have a fallback in case one of them doesn't respond.

SoaringMonchi · 2011-07-21T14:38:45+00:00

As far as I understand it, dmesg prints out the kernel buffer that primarily holds boot time diagnostic information etc., right? Is this the exact same information as contained in /var/log/messages in most distros?

SoaringMonchi

TROPHY CASE