Stop Exposing Ports With Nginx Proxy Manager on [Ubuntu Server](/blog/stop-uploading-your-memories-to-big-tech-self-host-immich) 24.04
If you’ve done any amount of self-hosting, you already know how fast things get messy. One app is on one port, another app is on a different one, and before long you’re trying to remember whether a service lives on an IP, a hostname, or some random high-number port you exposed weeks ago and forgot about.
That is exactly where Nginx Proxy Manager fits in.
For this setup, the goal is simple. Instead of exposing every service directly and keeping track of them one by one, you put a reverse proxy in front of your apps and manage access from a clean web interface. On Ubuntu Server 24.04, that gives you a much nicer way to publish self-hosted services, handle HTTPS with Let’s Encrypt, and avoid fighting raw Nginx configs if you do not want to.
Why exposing ports becomes a problem
Self-hosting is easy at the beginning because the first service feels straightforward. Open a port, connect to the IP, and you’re in. But once you start adding more apps, that approach becomes harder to manage.
A few common pain points show up quickly:
- You have to remember which service uses which port
- Access starts to depend on typing long URLs with custom ports
- SSL becomes another task to solve for every exposed app
- It gets harder to keep things organized as your homelab grows
That is why a reverse proxy matters. Instead of sending people to server-ip:port, you route traffic through a central entry point and map friendly domains or subdomains to the right backend service.
In plain English, it helps your setup feel intentional instead of patched together.
What Nginx Proxy Manager brings to the table
The big appeal here is not just that it is a reverse proxy. It is that it gives you a simple web UI to manage that reverse proxy.
That matters, especially for beginners.
Traditional Nginx configuration is powerful, but it can be intimidating if you are still learning Linux or building your first real homelab. Nginx Proxy Manager lowers that barrier by letting you manage proxy hosts, SSL, and related settings from a graphical interface.
Based on the walkthrough, the key value is this:
- Cleanly expose services
- Add HTTPS using Let’s Encrypt
- Manage everything from a simple web UI
- Avoid having to hand-build Nginx configs for basic use cases
That makes it a strong fit for people who are new to Linux, building out a homelab, or trying to develop practical infrastructure skills without getting buried in config syntax right away.
Who this is really for
This kind of setup is a sweet spot for a few groups.
If you are new to Linux, Nginx Proxy Manager gives you a way to understand reverse proxy concepts without needing to become an Nginx expert on day one.
If you are into homelab projects, it gives you a cleaner way to organize services as you add more apps over time.
And if you are trying to build real-world infrastructure skills, it is a practical stepping stone. You are still learning how services are published, how HTTPS is handled, and how domains map to internal applications. You are just doing it with less friction.
That last part is important. Tools like this are useful because they help you focus on architecture and workflow first. Once those ideas click, you can always go deeper later.
The Ubuntu Server 24.04 approach
The setup shown here uses Ubuntu Server 24.04 and installs Nginx Proxy Manager as a Docker-based stack.
That tells you a lot about the intended workflow.
Rather than manually installing every component directly onto the host, Docker is used to package and run the service in a more manageable way. That is a common and practical path for self-hosting because it keeps deployment cleaner and easier to reproduce.
The flow described in the video covers:
- Reviewing install options and documentation
- Making sure prerequisites are in place
- Dealing with domains, Docker, and port 80 concerns
- Installing Docker
- Creating the Docker Compose stack
- Logging into the Nginx Proxy Manager UI
- Creating a first proxy host
- Adding security and SSL-related protections
Even without stepping through every command here, the broader pattern is very clear. This is a Docker-based deployment on Ubuntu Server 24.04 with a web-managed reverse proxy sitting in front of your self-hosted apps.
Prerequisites matter more than people think
One of the most useful parts of this walkthrough is the attention given to prerequisites.
Before you even get to the cool part, there are a few things that need to be lined up:
- Your domain setup
- Docker availability
- Port 80 considerations
That last one is especially important.
If you are planning to use Let’s Encrypt for HTTPS, port 80 issues can become a real problem. The walkthrough specifically calls out port 80 concerns as part of the prerequisites, and that is a strong hint that this can block or complicate SSL setup if you ignore it.
A concrete gotcha to avoid
Here is one mistake to avoid: do not gloss over the port 80 requirement when planning SSL.
The walkthrough calls out "port 80 issues" before installation and later mentions "SSL gotchas" during the security section. That is your warning sign.
If you rush ahead without making sure port 80 is available and correctly handled, you can end up wondering why Let’s Encrypt is not working the way you expect. A lot of beginners assume the proxy UI is the hard part, but the real issue is often the networking and prerequisites underneath it.
So if HTTPS is part of your goal, treat that as foundational, not optional.
Docker and the Compose stack
The installation flow uses Docker and a Docker Compose stack for deployment.
That is a practical choice because Nginx Proxy Manager is the kind of service you want to deploy consistently and manage cleanly. Containers make that easier for a lot of home server setups.
The walkthrough also mentions installing Docker first and then creating the Compose stack. That means this is not a random one-off install. It is structured in a way that can be repeated and maintained, which is exactly what you want if your server is going to host multiple services over time.
For a lot of people, this is also one of the first times they start seeing how self-hosting pieces fit together:
- The host OS is Ubuntu Server 24.04
- Docker runs the application stack
- Nginx Proxy Manager acts as the front door
- Backend apps stay behind the proxy
That mental model is worth learning.
First login and the UI advantage
After deployment, the guide moves into first login and a UI tour.
This is where Nginx Proxy Manager starts making immediate sense for beginners. You are not dropped into raw configuration files hoping you remember syntax. You are working from an interface built around the tasks you actually care about.
That includes setting up proxy hosts and managing SSL in a way that is easier to visualize.
For people who have avoided reverse proxies because they assumed it would be all manual Nginx edits, this is usually the moment the tool clicks. You get the value of a reverse proxy without the same level of entry friction.
Creating your first proxy host
The walkthrough uses Jellyfin as the example for creating a first proxy host.
That is a great example because media apps are one of the most common reasons people get into self-hosting in the first place. Instead of sending users directly to a raw IP and port, you can publish that service more cleanly behind Nginx Proxy Manager.
The exact backend settings are not the point here. The bigger lesson is that once the proxy layer is in place, your services can be presented in a more organized way.
That has some immediate benefits:
- Friendlier access using domains or subdomains
- A central place to manage routing
- Easier SSL handling
- Less temptation to expose every app individually
If you are building out a homelab, that kind of consistency pays off fast.
Security tips and access lists
Security is another area where this setup starts to matter.
The guide specifically mentions security tips, access lists, and SSL gotchas. That tells you this is not just about making services reachable. It is also about being more deliberate with how they are exposed.
Access lists can help control who can reach what. Even at a basic level, thinking in terms of controlled access is a lot better than treating every app like it should be directly open.
And that is really the larger lesson here. A reverse proxy is not just a convenience tool. It is also part of building a more manageable and security-conscious setup.
When Nginx Proxy Manager makes sense, and when it might not
The walkthrough closes with a practical point that I really like: when to use NPM, and when not to.
That kind of framing matters because no tool is the answer for every situation.
From what is covered here, Nginx Proxy Manager makes a lot of sense when:
- You are self-hosting multiple apps
- You want cleaner external access
- You need HTTPS through Let’s Encrypt
- You prefer a web UI over hand-writing Nginx configs
- You are growing a homelab and want something more organized
At the same time, the fact that the video explicitly talks about when not to use it is a reminder to stay practical. If your environment is very simple or your needs are very specific, a heavier management layer may not always be necessary.
The right takeaway is not that everyone must use Nginx Proxy Manager. It is that once you start hitting the limits of raw port exposure, this is a strong next step.
Why this is worth learning
Even if your current setup is small, learning a tool like this helps you level up from "I got it working" to "I built it properly."
That is a big transition.
You start thinking less about individual ports and more about service delivery. You start thinking less about one-off access and more about repeatable structure. And you start seeing how tools like Docker, domains, reverse proxies, and SSL all fit together.
That is real infrastructure thinking, even in a home lab.
If you have been exposing ports for every app and hoping you remember what is where, this is the kind of cleanup move that can make your whole setup feel more professional and easier to live with.
Keep building, keep learning, and I’ll catch you in the next one.
~ KeepItTechie

