How to self-host Docker apps on a VPS

Prepare the server and access

You need a fresh VPS, root access for installation, a domain you can edit, and the app's deployment instructions. Identify its listening port, required environment variables, database, and writable directories before creating the service. Keep repository or registry credentials available if the source is private. This workflow assumes you can administer Linux; use a staging copy of an app you know for the first run.

Follow the current Easypanel installation guide. The script installation requires a fresh Ubuntu server with at least 2 GB of RAM and ports 80 and 443 available. That is an installation minimum; size the machine for your applications, databases, and builds using the VPS selection guide.

Assign someone to operating system updates, SSH access, firewall rules, disk capacity, and incident response. Restrict administrative access and verify the ports reachable from outside the server. Docker's port publishing rules can expose a service beyond its container network. Keep databases private unless you have a specific, controlled need for external access.

For an agency, record which client owns each app and who can access it. Projects help organize services, but a shared server remains a shared failure boundary. Use separate servers where client access or isolation requirements call for them.

Choose the deployment route

Choose based on how the application is maintained. You can run several App services in a project, or use Compose to keep a group of containers in one definition.

App service: a repository or image

Use an App service for a web app, API, or worker that you deploy individually. With GitHub or Git, select the repository, branch, and build path, then choose a builder. An existing Dockerfile gives you explicit build instructions. With Docker Image, supply the image reference and any registry credentials; Easypanel pulls that image instead of building it.

Compose service: a multi-container definition

Use a Compose service when the application ships a Compose file or you already maintain one. Paste the YAML or connect its Git repository. Check the build path and Compose filename. Resolve compatibility warnings about fixed container names and published ports; configure public HTTP routing in Easypanel's Domains section.

Template: an existing application recipe

Look in the template directory for packaged applications. Review the services, image versions, credentials, and storage it creates. Follow the application's own setup requirements and complete the verification and recovery checks below.

For private code, follow the GitHub token or Git SSH instructions. Grant only the access the deployment needs. For images, record a release version or digest so you can identify exactly what is running and redeploy it later.

Configure secrets and persistent data

Use the app's documented variables for its public URL, database connection, mail provider, and other dependencies. Enter real credentials in Easypanel's Environment section. Keep a separate, access-controlled recovery copy and leave secret values out of Git, screenshots, and support messages.

App environment values are available to both builds and running containers. Check that your build does not print credentials or embed server secrets in browser assets. For Compose, distinguish variables used to interpolate the YAML from values passed into a container's environment. Follow the Compose environment instructions and redeploy after changes.

List everything the app writes: database records, uploads, generated files, and any local application state. For an App service, configure the required mounts in Storage. For Compose, declare named volumes or explicit bind mounts in the file. Match each mount destination to the directory the app actually writes, and check permissions for its runtime user.

A persistent volume keeps data through container replacement. It still depends on the server's storage. Arrange an external backup before accepting production data.

Deploy and connect the domain

Save the configuration and select Deploy. Read its output until the build or image pull finishes, then inspect the runtime logs. If the app needs a database migration or an initial admin account, follow the app's instructions before opening it to users. Saving most App settings does not apply them to the running service until deployment.

Point the chosen hostname's DNS record to the server. In the service's Domains section, configure the hostname, HTTPS, and the internal port on which the app listens. The process normally needs to listen on 0.0.0.0 inside its container. For Compose, also select the internal service that handles web requests. Route to the web app, leaving its database and queue off the public domain.

See the App domain settings or Compose domain settings for the exact fields. Check that the app's configured public URL matches its HTTPS address, including authentication callback URLs and webhook destinations. Test redirects before making them permanent.

Check the application end to end

Run these checks on the staging copy before directing customers to it. Use representative data and a test account so that you can repeat the checks after every release.

1. Open the public HTTPS URL from outside the server and check the certificate and any redirects.
2. Sign in with a test account, create a record, and read it back. Exercise a background job if the app uses a worker.
3. Upload a test file, redeploy the same version, and confirm that the record and file are still available.
4. Inspect deployment and runtime logs for failed migrations, database connection errors, or repeated restarts.
5. Check memory and disk use during a build as well as normal traffic. Leave room for the other apps sharing the host.

Set up an external availability check and decide who receives the alert. A running container can still serve errors, and a monitor on the same VPS cannot report its own loss of power or network access.

Back up, then test a restore

Choose how much recent work the business can afford to lose and how long it can wait for recovery. Use those answers to set the backup schedule and decide whether a single-server setup is enough. Keep backup data outside the VPS and use a separate destination path for each configuration.

Easypanel's database backups create logical dumps for supported database services. Confirm your plan includes scheduling if you intend to use it. An App volume backup syncs a named volume to its destination: later runs can overwrite files or remove files deleted at the source. Use destination versioning or another backup method when you need older copies. Volume recovery is manual.

Bind mounts, File mounts, and volumes declared inside Compose need their own recovery plan; do not assume App volume backups cover them. Use a database-aware backup procedure for databases inside Compose. Copying a live database's data directory can produce an inconsistent copy.

Run each backup manually, check its log, and inspect the files at the destination. Then recover into a separate test service or server. Recreate the configuration, restore the database and uploaded files, and repeat the login, read, and write checks. Database restores can replace existing data, so verify the target before starting. For a consistent recovery point, prevent writes from web requests, workers, and scheduled jobs as needed.

Record the recovery steps and how long they took. Keep access to the backup provider, DNS, source code, and required secrets available even if the original server is gone.

Make the next release repeatable

Record the running source revision or image digest and retain the previous release. Test the new version in staging with the same configuration shape as production. Read the application's release notes for migrations, changed variables, and storage requirements; take a verified backup before a change that can modify data.

Deploy the update, watch the deployment output and runtime logs, and repeat your application checks. Enable automatic deployment only after you have decided which branch or pipeline is allowed to release to production. Treat a Deployment Trigger URL as a secret because it can start deployments.

Practice redeploying the known-good image or source revision. That reverts application code; it does not undo a database migration or restore deleted files. If the earlier code cannot use the new schema, recovery may require a forward fix or a restore with downtime and loss of writes since the backup. Decide that procedure before the release.

Find the failing step

The image never builds or pulls

Read the deployment output. Check repository or registry credentials, the image tag, build path, Dockerfile path, and any files the build expects. Check server memory and free disk space if the process is killed or runs out of storage.

The container starts, but the domain fails

Check the app logs and listening port first. The domain must target that internal port, and the process normally needs to listen on 0.0.0.0. For Compose, confirm the selected internal service. Then check DNS, public port access, and the certificate configuration.

The app cannot connect to its database

Check the hostname, port, database name, credentials, and network access from the app container. localhost refers to that container, so it usually cannot reach a separate database service. Confirm that the database has finished starting and that required migrations have run.

Uploads disappear after deployment

Compare the path where the app writes files with the mount destination. A volume mounted at the wrong path leaves those writes in the container filesystem. Also check ownership and write permissions for the image's runtime user.

A saved setting has no effect

Check whether you deployed after saving it. Most App configuration changes and Compose source or environment changes require a deployment. A restart does not rebuild your application from new source code.

Plan the rest of your setup