Site icon My WP Tips

Best Practices for Secure Root Access on Immich Server Installations

Running an Immich server feels a bit like owning a tiny photo museum. It stores family trips, pet chaos, food pictures, and memories you do not want to lose. But behind the pretty web app is a real server. And on that server, root access is the master key. Treat it like a dragon egg. Powerful. Useful. Also very dangerous if dropped.

TLDR: Do not use root for daily Immich work. Use a normal user with sudo, lock down SSH, and use SSH keys instead of passwords. Keep your server updated, limit access with a firewall, and back up your Immich data often. Root should be used only when needed, and every use should feel a little serious.

Why Root Access Matters

The root user can do anything on a Linux server. It can install software. It can delete files. It can change passwords. It can also break your Immich setup with one sleepy typo.

Immich usually runs with Docker or Docker Compose. That means there are containers, volumes, databases, upload folders, and config files. Many of these parts need careful permissions. If root owns the wrong thing, Immich may stop working. If an attacker gets root, they own the whole box.

So the goal is simple. Keep root access rare, controlled, and boring. Boring security is good security.

Do Not Log In as Root Every Day

This is rule number one. Do not use root as your normal account. It is like using a chainsaw to slice bread. It may work. But one mistake gets messy.

Create a regular user for server work. Give that user sudo rights. Then you can run admin commands only when needed.

For example:

adduser immichadmin
usermod -aG sudo immichadmin

Now log in as immichadmin. Use sudo only for tasks that need it.

This gives you two big wins:

Think of sudo as asking the server, “May I use the big hammer for one minute?” That is much safer than walking around with the hammer all day.

Disable Direct Root SSH Login

SSH is the front door to your server. If root can log in directly, attackers know the username already. They only need the password or key. That is not great.

Edit your SSH config:

sudo nano /etc/ssh/sshd_config

Find or add this line:

PermitRootLogin no

Then restart SSH:

sudo systemctl restart ssh

Before you close your current terminal, open a second one. Test that your normal user can log in. This avoids the classic “I locked myself out” dance. Nobody enjoys that dance.

Use SSH Keys, Not Passwords

Passwords can be guessed. Passwords can be reused. Passwords can be written on sticky notes that somehow end up on the internet. SSH keys are much better.

Create a key on your computer:

ssh-keygen -t ed25519

Then copy it to your server:

ssh-copy-id immichadmin@your-server-ip

After testing key login, disable password login:

PasswordAuthentication no

Restart SSH again:

sudo systemctl restart ssh

Also use a passphrase on your SSH key. Yes, it is one extra step. But it protects you if your laptop is stolen or cloned.

Limit Who Can Use Sudo

Not every user needs admin powers. Your Immich server is not a village meeting. Keep the admin group small.

Check who has sudo access:

getent group sudo

Remove users who do not need it:

sudo deluser username sudo

If you have friends or family using Immich, they should use Immich accounts. They should not have Linux users on the server unless they truly need them.

Small access is safe access. Give people only what they need. Nothing more.

Protect Your Docker Setup

Immich often runs in Docker. Docker is powerful. But Docker and root have a complicated friendship.

On many systems, users in the docker group can control containers as if they were root. That means the docker group is basically a secret admin club.

Check who is in it:

getent group docker

Only trusted admins should be there. Do not add random users to the Docker group. Do not add your cousin because they “know computers.” That is how raccoons get into the pantry.

Also keep your Immich Compose files in a controlled directory. For example:

/opt/immich

Set sensible ownership:

sudo chown -R immichadmin:immichadmin /opt/immich

Be careful with commands like chmod 777. That command means “everyone can do everything.” It is the security version of leaving your house keys in a cake.

Image not found in postmeta

Keep Secrets Secret

Immich uses environment files. These may contain database passwords, API keys, and other private settings. Do not share them. Do not paste them into public forums. Do not upload them to public GitHub repos.

Your .env file should be readable only by the admin user when possible:

chmod 600 .env

If you need help online, remove secrets before posting logs or config files. Replace passwords with fake values such as REDACTED. Attackers love real secrets. Give them confetti instead.

Use a Firewall

Your Immich server does not need every port open to the world. Open only what you use.

Common ports may include:

With UFW, you might use:

sudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

If you use a VPN, even better. You can keep Immich and SSH private. Then only VPN users can reach them. That is like putting your photo museum behind a secret garden gate.

Update Often, But Not Blindly

Updates fix bugs. Updates fix security holes. Updates also sometimes change behavior. So patch often, but be smart.

Update the operating system:

sudo apt update
sudo apt upgrade

Update Immich using the official Immich upgrade instructions. Read the release notes. Immich moves fast. That is exciting. It also means you should check for breaking changes before pulling new images.

Before big updates, make a backup. Always. Future you will send thank-you cookies.

Back Up Before Root Work

Root can delete things fast. Very fast. A bad command can remove uploads, database files, or config folders. Backups are your safety net.

For Immich, back up these key items:

Use the backup method recommended by Immich for the database. Do not just copy a live database folder and hope. Databases are picky. They like proper dumps.

Also test your restore process. A backup that has never been tested is just a wish with a filename.

Use Strong Logging and Alerts

Logs help you see what happened. They are the server’s diary. Sometimes the diary says, “Someone tried to log in 9,000 times at 3 a.m.” That is useful.

Check SSH login attempts:

sudo journalctl -u ssh

Check sudo use:

sudo journalctl | grep sudo

You can also install tools like fail2ban. It blocks repeated failed login attempts. It is like a tiny bouncer for your SSH door.

Install it with:

sudo apt install fail2ban

Default settings are often helpful. But review them. Make sure you do not block yourself, especially if your home IP changes often.

Avoid Running Immich Services as Root

Containers may start as root inside the container, depending on the image and setup. Follow the official Immich documentation here. Do not randomly change container users unless you know the effect. Immich services need correct file access.

Still, avoid extra root-powered services around Immich. Do not run random scripts as root. Do not run third-party “cleanup” tools without reading them. A script from the internet can be helpful. It can also be a raccoon with a keyboard.

If you automate tasks, keep scripts simple. Store them clearly. Review them before running with sudo. Use full paths in scripts when possible. Log what they do.

Use HTTPS

If you access Immich through a browser or mobile app, use HTTPS. This protects traffic between your device and the server. Without HTTPS, login data and session details may be exposed on unsafe networks.

Many users place Immich behind a reverse proxy such as Nginx Proxy Manager, Caddy, Traefik, or Nginx. These can manage TLS certificates. Let’s Encrypt certificates are free and widely used.

Root access may be needed to set up the proxy at first. After that, keep changes careful and documented.

Document Your Root Changes

This sounds boring. Do it anyway. Keep a small admin note file. Write down major changes.

Include things like:

This is not just for teams. It helps solo admins too. Three months later, you may not remember why port 2283 is closed or why a folder has strange permissions. Notes save brain energy.

Make an Emergency Plan

Security is not only about blocking bad things. It is also about recovering fast.

Have a plan for these moments:

If your server is a VPS, know how to use the provider console. If it is a home server, know how to access it with a keyboard and monitor. Store recovery keys somewhere safe. Not in the same place as the server. Not in a text file called passwords final final.txt.

Use Root Like a Chef Uses Fire

Fire cooks dinner. Fire also burns dinner. Root is the same. It is needed for updates, system config, firewall rules, and recovery. But it should not be your normal mode.

Before using root, pause for five seconds. Ask three questions:

If the answer is no, stop. Read more. Ask for help. Check official docs. Your photos are worth the extra minute.

Final Thoughts

Securing root access on an Immich server is not about being paranoid. It is about being kind to your future self. Use a normal admin user. Lock down SSH. Use keys. Keep Docker access tight. Protect secrets. Back up your data. Update with care.

Immich keeps your memories safe and searchable. Your job is to keep the server safe too. With a few smart habits, root access becomes less scary. It becomes just another tool. A powerful tool. A tool you keep in a locked drawer, with a label that says, “Use wisely, photo wizard.”

Exit mobile version