Encrypting Data on your Hosted Mac

The short version

The short version: FileVault full disk encryption is probably not what you need. Your Mac runs 24/7, and in that state FileVault does nothing. It only protects data when the Mac is powered off, which on a server is almost never. What you probably want instead is encryption you can lock and unlock on demand while the server is running.

First: what are you actually protecting against?

Before picking an encryption method, think about the actual threat you are worried about.

Someone breaking into your server over the network. This is the most realistic threat for any internet-connected server. An attacker exploiting a vulnerability, brute-forcing SSH, or getting hold of leaked credentials. No disk encryption helps here. If your server is running, the disk is already unlocked. Network security, strong authentication, firewalls, and keeping your software updated are what protect you against this.

Someone physically stealing the Mac from our data center. This is where disk encryption matters. If someone walks out with your Mac, encryption is what stops them from reading your data. But this is also where our physical security controls come in (more on that below).

Us (Green Mini host) accessing your data. Fair concern. We do not store your macOS passwords, SSH keys, or any other credentials. Our staff cannot log in to your server. But if you want a guarantee that even we cannot access your data, encryption where only you hold the key is the answer.

Compliance requirements. Some regulations or contracts simply require full disk encryption. If an auditor needs to see "full disk encryption: enabled," that is a valid reason on its own.

Knowing which of these you care about determines which encryption approach makes sense.

What we already do

Your Mac is not sitting unprotected. Before you add any encryption, this is already in place:

Physical security. Our data center uses multiple layers of electronic access control with logging, CCTV, high fences, etc. Only authorised staff can enter the server rooms.

No access to your credentials. We do not store your macOS passwords, SSH keys, or any authentication credentials for longer term. We cannot log in to your server by design, unless you provide us access for example for maintenance or debugging.

Secure decommissioning. When a Mac is decommissioned, we erase it using Apple's Erase All Content and Settings or DFU restore. This destroys the Secure Enclave keys and makes all data unrecoverable.

Your Mac's SSD is already hardware-encrypted

Every Apple Silicon Mac and every Intel Mac with a T2 chip (2018 and later) encrypts its SSD at the hardware level, all the time. The Secure Enclave handles this automatically. It cannot be turned off. The storage is soldered to the logic board, so nobody can pull it out and read it in another machine.

This means the only way to get at data on your Mac is to boot it and log in with valid credentials. That is already a strong baseline, and could tick the box of 'full disk encryption' - the traditional check where pulling a disk from a server in the DC is the threat.

FileVault: what it actually does (and does not do)

FileVault adds a password gate before the volume decrypts at boot. Without that password, the volume stays encrypted and even Recovery Mode cannot get in. That is real, strong protection.

But think about how your hosted server actually works. It is on, running, and the disk has been unlocked since the last boot. FileVault provides zero additional protection in that state. If someone compromises your server over the network, FileVault is irrelevant because the disk is already decrypted.

So what does FileVault protect against in practice?

• Someone stealing the physical Mac from our data center

• A rogue employee at our end resetting your password through Recovery Mode

These are legitimate concerns. But the first one is already addressed by our physical security. The second one is a trust question, and if that matters to you, FileVault is a reasonable choice.

The trade-off

FileVault prevents your Mac from booting unattended. After any reboot, whether from a power event, kernel panic, macOS update, or hardware issue, your Mac sits at the FileVault login screen and stays offline until someone enters the password.

macOS Tahoe (26) introduced remote unlock over SSH, which helps. You can SSH into the Mac at the pre-boot stage and type your password to unlock it. This requires Ethernet (Wi-Fi credentials are on the encrypted volume and not available yet), Remote Login enabled, and password-based SSH auth (key-based auth does not work at pre-boot). It is a real improvement, but it is still a manual step after every reboot. If power flickers at 3 AM while you are asleep, your server stays down until you act.

For details on setting up FileVault and using the Tahoe remote unlock, see our article FileVault on your Hosted Mac. Note that we consider this option still experimental.

What actually protects data on a running server

The encryption that makes the most difference on a 24/7 server is encryption you can lock while the server is still running. Mount it when you need it, do your work, unmount it when you are done. While unmounted, the data is encrypted and inaccessible, even to someone with root access on the Mac.

This does not interfere with boot, does not block reboots, and works on any macOS version. Your Mac comes back up normally after a power event, and your sensitive data stays locked until you explicitly unlock it.

Encrypted disk image (sparsebundle)

Create one:

hdiutil create -size 10g -encryption AES-256 -type SPARSEBUNDLE \
  -fs APFS -volname "SecureData" ~/SecureData.sparsebundle

You will be prompted to set a password.

Mount it when you need access:

hdiutil attach ~/SecureData.sparsebundle

Unmount when done:

hdiutil detach /Volumes/SecureData

A sparsebundle only uses as much disk space as the data actually stored in it, not the full size you set at creation. You can resize it later.

You can also create encrypted disk images using Disk Utility in macOS GUI.

Encrypted APFS volume

diskutil apfs addVolume disk3 APFS SecureVolume -passphrase

The volume requires the passphrase to mount and stays locked until you provide it.

Application-level encryption

Depending on your use case, you may not need volume-level encryption at all. Many applications and databases handle their own encryption: encrypted SQLite databases, GPG-encrypted files, or encryption of specific data fields within your application.

This gives you the most control. You decide exactly what gets encrypted and when it is accessible, without any filesystem-level overhead.

In any case, never store your keys/passwords on the same server - it makes the encryption pointless.

Comparison

Our recommendation

For most hosted servers, encryption you can lock and unlock on demand is more practical than full disk encryption that sits unlocked 24/7. An encrypted disk image or APFS volume lets you protect sensitive data while the server runs, without affecting boot or uptime. The keys stay with you.

Enable FileVault if you have a compliance requirement that demands it, or if you specifically want protection against the (unlikely) scenario of physical theft or password reset at our end. Just make sure you understand that it means manual intervention after every reboot.

Not sure what fits your situation? Contact us and we will help you figure it out.