Anyone running their own applications in containers knows the pattern: next to WordPress, n8n or your own web application there is almost always an extra container for nginx, Traefik or Caddy. On top of that comes a mechanism for SSL certificates that has to renew them regularly. This groundwork costs memory, time and attention - and it is a common source of errors when a certificate expires overnight.
In container hosting from SpeedIT Solutions, this part is already taken care of. A central reverse proxy that we operate, monitor and keep up to date sits in front of all projects. In this article we explain what it does for you, what you save as a result and when a web server container of your own still makes sense.
What is a reverse proxy?
A reverse proxy accepts requests from the internet and forwards them to the right application. To visitors it looks as if the response came straight from your website. In fact, the browser only talks to the proxy: it establishes the encrypted connection, checks whether access is allowed and then passes the request on to your container.
Your container only needs to do one thing: speak HTTP on a port. Whether that is port 80 for WordPress, 5678 for n8n or 3000 for your Node.js application does not matter. The platform does the rest.
What our reverse proxy does for you
- Automatic SSL certificates: For every web address we issue a certificate from Let's Encrypt and renew it well before it expires. You neither have to set up Certbot nor think about renewals.
- HTTPS enforced: Requests over HTTP are automatically redirected to HTTPS. We also send HSTS so that browsers only call your address encrypted from then on.
- Modern delivery: HTTP/2 and compression with zstd and gzip are active. Text, scripts and stylesheets reach your visitors noticeably smaller.
- WebSockets: Live connections, as used by chat tools, dashboards or n8n, are passed through without any extra setting.
- Real visitor IP: Your application receives the visitor's address in the usual headers such as X-Forwarded-For. Statistics, block lists and logs in your application work as usual.
- Smaller attack surface: The proxy hides the server signature and sets security headers such as X-Content-Type-Options. Your container cannot be reached directly from outside, only through the proxy.
- Access control per address: If you wish, you can open a web address only to certain IP addresses, such as your office or your VPN, protect it with a user name and password, or combine both. Ideal for admin interfaces, staging environments and internal tools.
- Adjustable upload size: You decide per address how large uploaded files may be.
- Data protection: We keep the proxy's access logs with IP addresses for a maximum of seven days. After that they are deleted automatically.
Your container only needs a port
You do not publish port 80 or 443 and you do not store any certificates in the container. In the customer area you simply enter the port your application listens on. The web address with SSL certificate is ready shortly afterwards, and a check chain shows whether address, certificate, container and application work together. The guide Making a container reachable on the web explains the details.
What you save
Without an upstream proxy, even a small WordPress installation quickly consists of three or four containers: application, database, web server as proxy and a helper for the certificates. With us, two are enough. That has very practical advantages:
- More resources for your application: The memory a proxy container would take up is available to your application.
- Less maintenance: We install security updates for the proxy. You only look after your own software.
- Fewer sources of error: No expired certificates, no wrongly set labels, no conflicts over port 443.
- Easier migration: You can take over an existing docker-compose file without having to rebuild the proxy part.
This is what a typical docker-compose file for WordPress with a database looks like, which you can import from docker-compose directly. It no longer contains a proxy container or certificates. The import takes WordPress port 80 as a suggestion for the web address, and the database sits in an internal network with no route to the internet.
services:
wordpress:
image: wordpress:6
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: datenbank
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: ${DB_PASSWORT}
WORDPRESS_DB_NAME: wordpress
volumes:
- wp-daten:/var/www/html
networks: [web, intern]
datenbank:
image: mariadb:11
environment:
MARIADB_DATABASE: wordpress
MARIADB_USER: wordpress
MARIADB_PASSWORD: ${DB_PASSWORT}
MARIADB_RANDOM_ROOT_PASSWORD: "1"
volumes:
- db-daten:/var/lib/mysql
networks: [intern]
networks:
web: {}
intern:
internal: true
volumes:
wp-daten: {}
db-daten: {}Your own images and private registries
Not every application comes from a public directory. Your own web applications, internal tools or customised variants of well-known software usually live in a private registry, for example the GitLab Container Registry, GitHub Packages or your own Harbor. You can connect such registries to container hosting as well - with authentication.
- Connect once: You enter the address of your registry, for example
registry.muster.de/team, and if required a user name and password or a token. - Approval by our team: We check the connection once and approve it, and you receive an email. From then on you use any image from this registry with its full address, such as
registry.muster.de/team/shop-api:2.3. - Protected credentials: We store them encrypted and use them exclusively for your own projects, never for other customers. You can change or remove them at any time in the customer area.
- Every version checked: Images from your own registry also go through the security check for known vulnerabilities before they start. For an update, you simply choose the new version.
docker-compose with your own images
When you import a docker-compose file, services may refer to images from your connected registry. The import recognises the approved registry and uses the stored credentials automatically - so passwords do not belong in the file. Images from the official sources such as Docker Hub or GitHub can be combined freely with your own. Services that are built from source with build have to be built beforehand, for example in your CI pipeline, and the finished image pushed to your registry.
This is what a file with your own application and an official cache can look like. The guide Creating a container explains how to connect a registry.
services:
api:
image: registry.muster.de/team/shop-api:2.3
ports:
- "3000:3000"
environment:
CACHE_HOST: cache
networks: [web, intern]
cache:
image: valkey/valkey:8
networks: [intern]
networks:
web: {}
intern:
internal: trueUse a read-only token
Create a dedicated token for the connection that can only read images - in GitLab, for example, a deploy token with the read_registry scope, in GitHub a token with read:packages. That keeps access limited to what is necessary, and you can revoke it at any time without touching your personal account.
When a web server container of your own still makes sense
For most applications the central proxy is entirely sufficient. However, there are cases in which you should also run your own web server such as nginx or Apache in a container:
- PHP-FPM images: Variants such as
wordpress:fpmornextcloud:fpmdo not include a web server, only PHP. They need a web server container in front that hands requests over to PHP. The variants with a built-in web server, such aswordpresswith Apache, are simpler. - Custom redirect and rewrite rules: When you need extensive redirects, rewrites or special headers that your application cannot set itself.
- Several services under one domain: If, for example,
/apiand/appshould lead to different containers under the same address, a web server of your own distributes the paths. - Caching and static files: For your own caching or for delivering large static files alongside the application.
- Special connection requirements: Such as client certificates or custom TLS settings. You publish such services via a dedicated TCP port instead of the web address.
Even then: your web server container sits behind our proxy. You still do not have to worry about certificates, HTTPS redirects or access control - your web server simply speaks HTTP internally.
Your own domain in a few steps
Every container with a web address first receives an address under our platform domain. You connect your own domain in the customer area: enter the domain, create a CNAME or A record with your provider, click "Check DNS". As soon as the record is correct, we issue the certificate automatically. A domain is only set up once the DNS record proves that it belongs to your project. That way nobody can point your domain at someone else's project.
Security behind the proxy: the platform
The proxy is only the first layer. Behind it, container hosting is built so that projects are cleanly separated from one another and you can see what is happening at any time:
- Rootless Podman: Containers run without root privileges. Every project has its own Linux user, fixed limits for memory, CPU, storage and processes, and its own storage area with a quota on fast NVMe storage.
- Checked images: Every image version is checked for known vulnerabilities before it starts. You see critical findings before the start and decide consciously.
- Networks and firewall: Internal networks have no route to the internet - ideal for databases. You allow outgoing connections completely or only to specific destinations. More on this under Networks and firewall.
- Nightly scan: Your volumes are checked every night for malware and known backdoors, and we report findings to you by email and in the customer area.
- Snapshots and backups: Snapshots take you back within seconds after a failed update, and the backup option stores your data encrypted in a separate data centre every night (Backup and snapshot).
- Located in Germany: Operated in Germany and GDPR compliant, with two-factor login in the customer area and personal support.
You can find an overview of all protective measures in the article Security in container hosting.
Frequently asked questions
Do I need my own SSL certificate for my container hosting?
No. For every web address, including your own domain, we automatically issue a certificate and renew it in good time. You do not have to upload or renew anything.
Can I still use nginx, Traefik or Caddy in my project?
Yes. If you need special rules or path routing, you run your web server as a perfectly normal container. It then sits behind our proxy and speaks HTTP internally - you do not need to take care of certificates in this case either.
My application only speaks HTTPS. Does that work?
Yes. Switch on the setting "Container speaks HTTPS" for the web address. The proxy then connects to your container in encrypted form.
Does my application see the real IP address of visitors?
Yes. The proxy passes on the visitor's address in the usual headers such as X-Forwarded-For. Many applications evaluate this automatically, for some you set the proxy as trusted.
Can I open an admin interface only to my office?
Yes. For each web address you decide whether it is public, reachable only from certain IP addresses or networks, protected by a password, or a combination of both.
Can I use images from my private registry, including with authentication?
Yes. Connect your registry, such as GitLab, GitHub Packages or Harbor, with a user name and password or token in the customer area. After our one-time approval you use the images directly in the wizard and when importing from docker-compose. We store the credentials encrypted and only for your projects.
What about services that do not speak HTTP?
For databases, game servers or other protocols you publish a dedicated TCP or UDP port. You decide in the project firewall who may reach this port.
Conclusion
An upstream reverse proxy takes the most tedious work in container hosting off your hands: certificates, HTTPS, compression and access control simply run along. Your containers concentrate on the application, and your resources go into what benefits your visitors. You only need a web server container of your own if you really require advanced rules or configurations - and even then, encryption remains the platform's job.
