What is Self Hosted Services?
Updated: 3 days ago
Self Hosted Services are applications that you run on infrastructure you control instead of relying entirely on a third party cloud platform to operate them for you. The service might run on a home server, NAS, mini PC, virtual machine, container host or rented server. The important distinction is control of the hosting environment: self hosting does not automatically mean the software is open source, free, private or located inside your home.
For UK broadband users, the practical question is not only what you can self host but how the service will be reached. A service used only on your home network may need no internet access at all. Remote access can involve a VPN, an outbound tunnel, IPv6, or conventional inbound connectivity using a public IPv4 address and carefully configured firewall rules. CGNAT can prevent normal inbound IPv4 port forwarding, so the access method matters as much as the server.
What does self hosted mean?
Self hosted means that you operate the software on computing infrastructure you control. That infrastructure can be physically yours or a server you rent, but you are responsible for substantially more of the operating environment than you would be with a fully managed cloud service.
Docker describes self hosting as running software on infrastructure you control and notes that this can include your own hardware, a rented server or a mixture of both. This also separates self hosting from software licensing: open source software can be cloud hosted, and closed source software can sometimes be self hosted.
A Home Lab often provides the infrastructure used to learn self hosting, while Docker and a Virtual Machine are two common ways of isolating services on the same physical host.
What can you self host?
File storage and synchronisation, including personal cloud storage and document services.
Media servers for music, films, television libraries and personal photos.
Home automation platforms and dashboards.
Password managers, note taking tools, wikis and knowledge bases.
Monitoring, logging and network management tools.
Development environments, source control, databases and internal web applications.
Websites, APIs and other services intended for authorised remote users.
DNS filtering, VPN endpoints and other network services when configured securely.
These are categories rather than recommendations. Each application has its own security model, resource requirements, backup needs and update process.
How do Self Hosted Services work?
At the simplest level, a server runs an application and listens for connections on an IP address and port. A client such as your laptop or phone connects to that service. If both devices are on the same LAN, the traffic can remain local and your broadband connection is not necessarily involved.
Many home setups use containers because they package applications and dependencies into isolated environments. Docker documentation and Tailscale documentation both describe containers as a practical way to separate services that might otherwise have conflicting dependencies. Virtual machines provide a different isolation boundary by running guest operating systems above a hypervisor.
A typical path for a local service is: client device → Ethernet or WiFi → switch or router → server → application. A remote service adds the internet and an access method. The narrowest or least capable part of that path can become the bottleneck.
Local access vs remote access
Local only services
A service bound only to a private address can be useful without being exposed to the public internet. Local dashboards, file servers and management interfaces are often safer when access is limited to trusted networks.
VPN or private overlay access
A VPN can provide remote access without making each application directly public. Tailscale states that its encrypted connections use WireGuard and can connect devices across NAT and firewalls without conventional port forwarding. For the underlying protocol, see What is WireGuard?.
Outbound tunnel access
An outbound tunnel reverses the normal exposure model: software on the server establishes an outbound connection to a tunnel provider. Cloudflare documents this approach for private applications and services such as SSH. This can avoid requiring a publicly routable inbound IPv4 address, but it introduces dependency on the tunnel provider and its access controls.
Direct inbound access
Traditional direct access can use a public address, firewall rules and port forwarding for IPv4 NAT. This approach requires particular care because the service becomes reachable from outside the home network. Do not expose administration interfaces merely because port forwarding is technically possible.
How CGNAT changes self hosting
Carrier Grade NAT places multiple customers behind shared public IPv4 addressing. If your broadband connection is behind CGNAT, an inbound IPv4 connection cannot normally be forwarded by changing only your home router because the provider controlled NAT layer sits upstream.
That does not make self hosting impossible. Local services still work, and remote access can use alternatives such as a private overlay network, an outbound tunnel, native IPv6 where the service and firewall are configured correctly, or a broadband product that provides suitable public addressing. The right option depends on the ISP, access network, product and location.
Does self hosting need fast broadband?
Not necessarily. Local traffic between devices on your LAN can avoid the broadband connection entirely. Broadband becomes important when users outside your home upload to or download from the self hosted service.
For remote users, upload capacity at the host location is especially important because data leaving your server travels upstream over your broadband connection. An asymmetric connection can therefore feel very different when serving files remotely even if its advertised download speed is high. This is why bandwidth should be considered separately in each direction.
Techie Broadband calculation: serving a 10 GB file remotely
Assumption: a decimal 10 GB file contains 80 gigabits. Theoretical transfer time equals file size in bits divided by the available transfer rate. These are ideal mathematical examples, not promises of application performance.
20 Mbps upload: 80,000 megabits ÷ 20 Mbps = 4,000 seconds, or about 66 minutes 40 seconds.
100 Mbps upload: 80,000 megabits ÷ 100 Mbps = 800 seconds, or about 13 minutes 20 seconds.
500 Mbps upload: 80,000 megabits ÷ 500 Mbps = 160 seconds, or about 2 minutes 40 seconds.
1 Gbps upload: 80 gigabits ÷ 1 Gbps = 80 seconds.
2.5 Gbps upload: 80 gigabits ÷ 2.5 Gbps = 32 seconds.
Real transfers take longer because of protocol overhead, encryption, storage speed, CPU load, congestion, application behaviour and other traffic. The remote user's own connection can also be the limiting factor.
Self hosting and your home network
Fast broadband does not fix a slow LAN. A self hosted service may be constrained by a 1 Gbps Ethernet interface, WiFi conditions, storage performance, CPU processing or a switch port even when the broadband connection itself is multi gigabit.
A 1 Gbps Ethernet link has a theoretical line rate of 1 gigabit per second, equivalent to 125 megabytes per second before protocol and application overhead. If a NAS can only write at 80 MB/s, upgrading the internet connection alone will not make a local file copy exceed the storage bottleneck.
Benefits of Self Hosted Services
Control: you decide where the service runs and how it is configured.
Data location: you can keep selected data on infrastructure you operate.
Flexibility: services can be integrated with your own network and automation.
Learning: running services develops practical Linux, networking, storage, virtualisation and security skills.
Cost structure: existing hardware can reduce subscription spending for some workloads, although electricity, hardware replacement, domains, backups and your time still have a cost.
What are the downsides?
Security responsibility moves towards you.
Updates and vulnerability management need ongoing attention.
Hardware can fail and data can be lost without tested backups.
Home power and broadband outages can make remote services unavailable.
Residential upload speeds can limit remote performance.
Noise, heat and electricity use can matter with larger servers.
Troubleshooting becomes your responsibility.
Some cloud services provide redundancy, support and scale that are difficult to reproduce at home.
Security responsibilities when self hosting
Self hosting gives control, but control is not the same as security. A poorly maintained server can create a new route into the rest of your network. Minimise public exposure, use strong authentication, apply security updates, separate sensitive workloads where appropriate and keep independent backups.
For remote administration, prefer an access method designed around authentication and encryption rather than exposing a management dashboard directly. Cloudflare recommends adding Access controls to self hosted applications exposed through its tunnel products, while Tailscale uses identity based policies for access within a tailnet.
Also remember that a backup stored only on the same server is vulnerable to the same hardware failure, accidental deletion or compromise as the primary data.
A practical Self Hosted Services setup
Choose one service and define whether it needs local access, remote access or both.
Choose suitable hardware such as a mini PC, NAS or existing computer and confirm its CPU, memory, storage and network capabilities.
Decide whether to install directly on the operating system, inside a container or inside a virtual machine.
Give the host a stable local addressing arrangement so clients can find it reliably.
Install the service and test it locally before configuring any remote access.
Configure authentication, updates, firewall policy and least privilege access.
Choose a remote access method only if remote access is genuinely required.
Create a backup plan and test that data can actually be restored.
Monitor storage, resource usage, logs and availability over time.
Troubleshooting a self hosted service
Confirm the server is powered on and the application or container is running.
Test the service from the server itself using its local listening address where appropriate.
Test from another device on the same LAN to separate application problems from remote access problems.
Confirm the server IP address, listening port and firewall rules.
Check whether the client and server are on networks that are allowed to communicate.
Check DNS only after confirming that direct IP connectivity works where the protocol permits it.
For remote access, determine whether you are using direct public addressing, IPv6, a VPN or a tunnel.
If relying on inbound IPv4, check whether CGNAT or double NAT prevents the connection from reaching your router.
Check upload bandwidth, latency, packet loss, server CPU and storage if the service works but performs poorly.
Review application, reverse proxy, tunnel and firewall logs before changing multiple settings at once.
Self hosted vs cloud hosted
Self hosted: you control more of the infrastructure and accept more operational responsibility.
Managed cloud: the provider operates more of the underlying platform, often including redundancy, updates or scaling depending on the service.
Hybrid: some components run locally while others use cloud infrastructure, remote backups, identity services or tunnels.
Neither model is universally better. The right choice depends on the data, availability requirement, security capability, cost, performance needs and how much maintenance you want to own.
Common misconceptions about self hosting
Self hosted does not necessarily mean open source.
Self hosted does not necessarily mean free.
Self hosted does not necessarily mean the server is physically in your home.
Self hosted does not automatically make data private or secure.
Self hosted services do not all need to be reachable from the public internet.
A static public IPv4 address can simplify some direct access designs, but it is not mandatory for every self hosting method.
Faster download speed does not automatically make a home server faster for remote users; host upload capacity and the full end to end path matter.
Frequently asked questions
Do I need a server to self host?
You need a device capable of running the service, but it does not have to be enterprise server hardware. A mini PC, NAS, old computer or suitable single board computer can be enough for lighter workloads.
Can I self host behind CGNAT?
Yes. Local hosting is unaffected, and remote access can use methods that do not depend on conventional inbound IPv4 port forwarding, such as suitable VPN overlays or outbound tunnels. Native IPv6 may also be an option when both ends and the firewall configuration support it.
Do I need a static IP address?
No. A static public IP can make some direct inbound designs simpler, but dynamic DNS, IPv6, private overlay networks and outbound tunnels provide other approaches. The correct choice depends on the service and threat model.
Is Docker the same as self hosting?
No. Docker is a container platform that can be used to run self hosted applications. Self hosting describes who controls the infrastructure, while Docker describes one way applications can be packaged and run.
Is self hosting safe?
It can be operated securely, but safety depends on configuration and maintenance. Exposing services unnecessarily, delaying updates, using weak authentication or relying on untested backups increases risk.
Does self hosting save money?
Sometimes, but not automatically. Compare subscription costs with hardware, electricity, replacement drives, backup storage, domains and your own time. Self hosting is often chosen for control and learning as much as direct cost saving.
Key takeaway
Self Hosted Services give you control over where applications run, how they are configured and, in many cases, where data is stored. The trade off is responsibility: you become more accountable for security, updates, backups, availability and troubleshooting. For UK home users, broadband architecture matters most when services need remote access, particularly upload capacity, CGNAT, public addressing and the chosen secure access method.
To explore the related technical concepts used in this Self Hosted Services guide, visit our broadband terminology guide.
