Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteYes—you can host many Dokku applications on one server while sharing public ports 80 and 443. Dokku gives each app its own hostname, then nginx uses virtual-host routing to send a request to the matching app. The apps can use different internal container ports; users still reach them through their normal domains.
Antihost offers VPS plans with one-click Docker, NVMe storage and a 14-day free trial.
The reliable sequence is: point every domain or subdomain at the server, deploy each app under a unique Dokku app name, assign its hostname with Dokku’s domains commands, verify proxy mappings, and enable HTTPS separately for each app. If a domain list changes later, renew the affected certificate so its names remain synchronized.
As an Amazon Associate I earn from qualifying purchases.
How Dokku routes several apps through one server
A Dokku installation can run multiple applications as separate deployments. Each application has its own Dokku name, source, process configuration and domain list. At the edge, nginx examines the hostname in the incoming HTTP or HTTPS request and selects the virtual host associated with that app.
That is why several apps can share the same public listener. The browser connects to port 80 or 443 on the server; nginx distinguishes app1.example.com from app2.example.net and forwards each request to the correct application. The port exposed inside a container does not need to be the same for every app.
| Layer | What is unique per app | What can be shared |
|---|---|---|
| Application identity | Dokku app name, deployment and configuration | The Dokku host |
| Public address | One or more domains or subdomains | Server IP address and public ports 80/443 |
| Routing | nginx virtual-host entry and proxy target | nginx service |
| Container listener | The internal port on which that app listens | Only when the applications happen to use the same internal port; Dokku maps them independently |
| TLS certificate | Certificate covering that app’s domain list | The Let’s Encrypt plugin and nginx reload process |
Dokku’s global domain can provide defaults, but an app’s explicitly assigned domains take precedence. The official domain documentation describes the default behavior this way: “The subdomain is inferred from the pushed application name, while the domain.tld is set during initial dokku configuration.” For a multi-domain server, explicit per-app assignments are clearer and prevent an app from receiving an unintended hostname.
What you need before deploying
- A Dokku server with a public IPv4 address, and an IPv6 address if you intend to publish AAAA records.
- Control of DNS for every domain or subdomain you will use.
- A unique Dokku app name for each deployment.
- A source repository that Dokku can build with a supported Heroku buildpack, a Dockerfile, or a Docker image.
- Administrative access to run Dokku commands on the host.
- For automated Let’s Encrypt certificates, DNS that already resolves each app hostname to the server’s public IP. Dokku’s deployment documentation states that all domains on an app must point correctly to that IP for automated SSL validation.
Dokku’s documentation does not publish a universal maximum number of apps per host, deployment-time guarantee or performance benchmark. The practical limit depends on the server’s available resources and the applications’ own workloads, so size the host for the combined deployments rather than assuming a fixed app count.
Step 1: Create DNS records for every hostname
For each app, create an A record pointing its domain or subdomain to the Dokku server’s public IPv4 address. If the server provides IPv6 and the app should be reachable over IPv6, create the corresponding AAAA record as well.
Examples of distinct hostnames include:
app1.example.comfor the first app.app2.example.netfor the second app.shop.example.comandapi.example.comwhen both apps use subdomains under one DNS zone.
Do not point two unrelated apps at different IP addresses and expect Dokku to choose between them. All names intended for this Dokku host must resolve to that host’s public address. DNS changes can take time to appear at recursive resolvers, so verify resolution before requesting certificates.
There is no requirement that all apps share the same parent domain. Separate registered domains work as long as their DNS records lead to the same Dokku server and you control those zones.
Step 2: Create and deploy each Dokku app
Use a distinct app name for every deployment. The name is the identifier used in later domains:, ports: and letsencrypt: commands; it is not required to be the same as the public domain.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →From each local repository, add a Dokku Git remote and push the branch you want Dokku to build:
# deploy the first repository
git remote add dokku dokku@SERVER:app1
git push dokku main
# deploy the second repository
git remote add dokku dokku@SERVER:app2
git push dokku mainReplace SERVER with the server address and use the actual app names. If a repository already has a remote named dokku, update that remote or choose another local remote name instead of adding a duplicate.
Dokku supports Heroku buildpacks, Dockerfiles and Docker images. The build method changes how the container is produced, but the hostname workflow remains the same: deploy first, then make the intended domain list explicit and verify the resulting proxy mapping.
Step 3: Assign one or more domains to each app
Run the commands on the Dokku host (or through the Dokku administration interface you use for host commands):
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11dokku domains:set app1 app1.example.com
dokku domains:set app2 app2.example.netdomains:set replaces the app’s domain list with the names supplied in the command. If an app must answer for an additional hostname without discarding its existing names, add it instead:
dokku domains:add APP extra.exampleUse the real app name in place of APP. Multiple names on one app are useful for an alias, a migration hostname or a second domain that should reach the same code. They are not a way to send one hostname to several different apps; a given hostname should belong to one intended virtual host.
Confirm what Dokku believes the app’s domains are:
dokku domains:report app1
dokku domains:report app2Review the report after every domain change. It provides an early check that the command targeted the correct app and that the expected names are present before you troubleshoot DNS or TLS.
Free tools Windows power users keep installed
One-click scans. No signup required.
Step 4: Verify public and internal port mappings
Public HTTP and HTTPS use ports 80 and 443 on the server. Dokku maps those listeners to each application’s internal container port. Inspect the generated mapping for each app:
dokku ports:report app1
dokku ports:report app2Most deployments follow Dokku’s normal web-port behavior. A Dockerfile or image deployment may use mappings in the form http:80:<container-port> and https:443:<container-port>. The exact container port must match the port on which the application actually listens.
Why non-standard ports need special attention
Dokku warns that assigning a domain before deployment can create proxy mappings that do not automatically match an app using a non-standard container port. This is an ordering problem: Dokku may not yet know the port exposed by the eventual image or Dockerfile when it creates the initial mapping.
If the report shows a target port that differs from the application’s listening port:
- Confirm the port exposed or configured by the Dockerfile or image.
- Inspect the app’s current result with
dokku ports:report APP. - Correct the proxy mapping using the port configuration appropriate to that deployment.
- Redeploy or reload the app as required by the change, then run the report again.
Do not diagnose a hostname problem when the hostname is correct but nginx is forwarding to a port where the container is not listening. A wrong internal target can produce connection failures even though DNS and the domain list are perfect.
Step 5: Enable HTTPS for each app
Automated certificates are provided by Dokku’s optional Let’s Encrypt plugin. Install and configure that plugin according to Dokku’s current deployment instructions, set its global contact email, and then enable certificates per app.
Once DNS is live and the app has the intended domain list, run:
dokku letsencrypt:enable app1
dokku letsencrypt:enable app2The plugin requests certificates for the app’s domain list and reloads nginx after successful issuance. Because validation is hostname-based, every name included in the list must resolve to this server and be reachable through the expected HTTP routing path.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
For Dockerfile or image deployments, the Let’s Encrypt documentation describes standard http:80:<container-port> and https:443:<container-port> mappings and explains when it injects them automatically. Check the resulting port report rather than assuming an automatic mapping matches a custom application port.
Step 6: Keep certificates synchronized after domain changes
A certificate represents the names requested at issuance time. Adding a hostname with dokku domains:add, replacing names with domains:set, or otherwise changing an app’s domain list changes the names that should be covered.
After DNS for the new name points to the server, run Let’s Encrypt enablement again for that app:
dokku letsencrypt:enable APPThis reissues or updates the certificate so its subject-alternative-name list includes the current domains. Without that renewal step, nginx may route the new hostname correctly while presenting a certificate that does not include it.
Recommended Free Tools
Separate domains, subdomains or aliases: choosing an arrangement
Dokku supports all three patterns. The right choice depends on who controls DNS, how independently the apps should be operated and how often names change.
| Arrangement | DNS requirement | Certificate implication | Operational meaning |
|---|---|---|---|
| Separate registered domains | Each domain’s A/AAAA records must point to the Dokku server; you need control of each DNS zone. | Each app’s certificate covers its own domain list; changing a name requires updating that list and reissuing. | Strongly distinct public identities and independent ownership boundaries. |
| Subdomains under one domain | Create a record for every app subdomain in the shared zone. | Each app can have a certificate for its assigned subdomain names. | Centralized DNS administration and a consistent public naming scheme. |
| Multiple domains on one app | Every alias must resolve to the same Dokku server. | The certificate must include every alias; rerun Let’s Encrypt enablement after additions or changes. | Several hostnames intentionally reach one deployment, such as an alias or migration address. |
These are deployment choices rather than performance guarantees. Dokku’s official documentation establishes the domain-list and certificate behavior; isolation preferences, DNS ownership and naming policy should be decided by your team.
End-to-end command pattern
The following compact sequence shows the relationship among deployment, domains, port checks and certificates. Substitute your actual server, app names, domains and container ports.
# deploy app1 and app2 from their repositories
git remote add dokku dokku@SERVER:app1
git push dokku main
git remote add dokku dokku@SERVER:app2
git push dokku main
# assign separate hostnames
dokku domains:set app1 app1.example.com
dokku domains:set app2 app2.example.net
# inspect domains and proxy mappings
dokku domains:report app1
dokku domains:report app2
dokku ports:report app1
dokku ports:report app2
# enable certificates after DNS is live
dokku letsencrypt:enable app1
dokku letsencrypt:enable app2Run the certificate commands only after the hostnames resolve to this server and the applications are serving the expected web ports. If you add another domain later, update DNS, add the name, check ports, and run the Let’s Encrypt command again for that app.
Troubleshooting by symptom
The domain opens the wrong app
- Run
dokku domains:reportfor every app involved and look for the hostname assigned to more than one app. - Check that the browser is using the exact hostname represented in DNS; a bare domain and a
wwwsubdomain are different names. - Confirm that the DNS A and AAAA records both lead to the intended Dokku server. An outdated AAAA record can send IPv6 clients elsewhere even when the A record is correct.
The domain does not reach any app
- Verify the DNS records and wait for resolver caches to reflect the change.
- Confirm the app was actually deployed under the name used in the domain command.
- Run
dokku domains:report APPanddokku ports:report APP; a missing domain or incorrect target port must be fixed on the Dokku host.
HTTP works but HTTPS validation fails
- Ensure every domain in the app’s list resolves to the server’s public IP, as required for automated Let’s Encrypt validation.
- Check that nginx is forwarding HTTP port 80 to the application’s real internal port.
- Remove or correct stale domain names before requesting a certificate; a single name that points elsewhere can prevent issuance for the requested set.
A newly added hostname shows a certificate warning
Routing and certificate coverage are separate. Confirm the name with dokku domains:report APP, make sure DNS is live, then run dokku letsencrypt:enable APP again so the certificate’s names match the current domain list.
The app responds with a connection error after deployment
Inspect dokku ports:report APP and compare the mapped target with the port exposed by the Dockerfile or image. Non-standard container ports are the documented case in which a domain assigned before deployment may not receive the correct mapping automatically.
Pre-launch checklist for every app
- Choose a unique Dokku app name.
- Create A and, when applicable, AAAA records for every intended hostname.
- Deploy the repository, Dockerfile or image.
- Set the app’s complete domain list with
dokku domains:set, or add an alias withdokku domains:add. - Verify the names with
dokku domains:report. - Verify public-to-container mappings with
dokku ports:report. - Correct any non-standard target-port mismatch.
- Configure the Let’s Encrypt plugin’s global email.
- Run
dokku letsencrypt:enable APPafter DNS resolves to the server. - Repeat the certificate command whenever the app’s domain list changes.
Following this order lets nginx use hostname-based routing while all applications share the server’s public HTTP and HTTPS ports. The critical invariants are simple: every hostname must resolve to the Dokku host, every app must have an unambiguous domain list, and each proxy mapping must point to the container port that actually serves that app.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →
