Adrian Lee

I’ve taken the second approach you mentioned: I own the domain, host my email with a service provider (I use Zoho Mail), and manage my DNS through Cloudflare. Here are three insights I’ve gained from this experience.

First, by managing your email provider and domain DNS separately, if you ever want to switch providers in the future, you’ll only need to update the MX and a few TXT records. Your email address will remain the same, and others won’t even notice.

Second, set up SPF, DKIM, and DMARC right from the start. Be sure to enter the recipient address for DMARC aggregate reports so you can receive daily reports showing which servers are sending emails using your domain and whether they’ve passed verification.

Third, even if a new domain passes all three checks, emails sent to Outlook may still end up in the spam folder at first. This is because the new domain lacks a reputation. It’s not a configuration error, and it takes time to gradually build that reputation.

This week, I’ve mainly been handling the fallout from the PHP vulnerability that occurred in late October. Following that incident, I made a few changes: I’ve opened only the necessary ports to the outside world, and the admin panel is now accessible only via VPN. I’ve created an inventory list for each server, clearly detailing which services are running and their versions, so that the next time a CVE is released, I’ll know immediately which servers are affected. In addition to running daily automatic backups, I periodically restore them to a clean machine to verify they work.

Remember: Always treat your servers as if they might be lost tomorrow, and make sure to have a thorough recovery plan in place.

I would never do something like that. It’s actually a sad story: I had a server that had to be exposed to the public, and not long ago, it was compromised by the latest PHP vulnerability. Fortunately, the damage wasn’t too severe. Since then, my policy has been to only expose services to the public that must be accessible to strangers, and I never expose administrative access points to the public internet. SSH access is restricted to key-based authentication, and the admin panel is accessible only from the internal network or via VPN. Two-factor authentication protects against password guessing, but it cannot prevent vulnerabilities that can be exploited before the login process even begins.

My server was recently compromised via the latest vulnerability. Fortunately, the damage wasn’t too severe. Since my server must remain publicly accessible, it can’t be hidden behind a VPN—I can only minimize its exposure as much as possible while ensuring my backup and recovery processes are rock-solid. I’ve configured the firewall to allow only essential ports, restricted SSH access to key-based authentication, enabled automatic installation of security updates, and set up daily backups, one of which is synchronized to an off-site location. Some have suggested treating public-facing machines as if they’ve already been compromised by default. I agree with this approach, and it’s exactly what I plan to do next.

The ability to set up a whitelist of channels and playlists based on user preferences sounds great—it’s perfect for sharing with family or friends. By the way, does the small instance you mentioned with 2 GB RAM include components such as the database, cache, downloads, storage, and media proxy? If I want to use a full instance, what server configuration would you recommend?