VPS Tutorials
Setting Up 1Panel on a VPS (2026): Installation, Docker Apps, HTTPS, Backups and Security Hardening
Install 1Panel on an Ubuntu/Debian VPS, then set up Docker apps, website reverse proxy, domain HTTPS, database isolation, off-site backups, security hardening and common troubleshooting.
If you want to deploy WordPress, Halo, Open WebUI, databases and Docker apps on a VPS without memorizing a pile of commands long-term, 1Panel is an easy choice to get started with. It brings host monitoring, files, containers, an app store, databases, scheduled tasks and backups together into one web panel, which suits individual site owners, small teams and home labs.
But 1Panel is not a security layer you can "install and forget." The panel itself, Docker, databases, domains, certificates and backups still need to be configured correctly. This article follows a production-ready order, starting from VPS selection and installation, to build a baseline environment with HTTPS, Docker apps, databases and off-site backups.
1Panel suits the following kinds of needs:
- You want to manage a Linux VPS through a web interface instead of doing everything over SSH;
- You need to quickly deploy WordPress, Halo, MySQL, PostgreSQL, Redis or common Docker apps;
- You want a unified view of CPU, memory, disk, network, containers and scheduled tasks;
- You need to manage multiple sites, domains, certificates and backup tasks;
- You want to run several self-hosted services on one machine but don't need Kubernetes yet.
If you only run a single static website, Caddy or Nginx config files are lighter; if you need team-level CI/CD and multi-machine orchestration, Dokploy, Coolify or Kubernetes are better fits. 1Panel's strength is consolidating common single-server operations work, not replacing all of your infrastructure.
1Panel itself doesn't use much in the way of resources; what actually consumes resources is the apps you install. The official online installation documentation states a minimum of 1GB of available memory, but that only means the panel can start, not that it's suitable for production.
| Use case | Recommended specs | Notes |
|---|---|---|
| Managing only Docker and a few tools | 2 cores, 2GB, 40GB SSD | Suits personal experiments and low-traffic services |
| Single WordPress or Halo site | 2 cores, 4GB, 60GB NVMe | Leaves headroom for database, PHP and cache |
| Multiple websites and Docker apps | 4 cores, 8GB, 100GB NVMe | Suits small teams and multiple self-hosted services |
| Open WebUI, databases and automation coexisting | 4 cores, 8GB minimum, 120GB+ NVMe | Model files and container logs fill disk quickly |
When buying a VPS, also confirm IPv4, snapshots, backups, outbound traffic and disk expansion pricing. 1Panel can only manage the server; it cannot change the provider's network quality or billing rules. You can first refer to our How to Choose VPS Specs and How to Prevent Runaway Bills on Pay-As-You-Go Cloud Servers.
We recommend a fresh Ubuntu 22.04/24.04 LTS, Debian 12 or another officially supported distribution. Do not layer 1Panel directly on top of a machine that already has Baota, aaPanel, old Docker, Nginx and multiple PHP versions installed; ports, services and Docker configuration can easily overwrite each other.
Prepare a panel domain, for example panel.example.com, and point the A record to the VPS IPv4. You can initially set DNS to DNS-only resolution, then decide whether to enable proxying after the certificate is issued successfully. Keeping the panel domain separate from business domains makes access control easier later.
Before installing the panel and changing SSH and firewall settings, confirm that your cloud provider offers a Web Console, VNC or Rescue Mode. If you lock yourself out of SSH, you can restore configuration from the console. For firewall operations, you can also refer to Recovery Checklist When SSH Is Unreachable After Enabling UFW.
sudo apt update && sudo apt full-upgrade -y
sudo reboot
After rebooting, first verify disk and memory:
df -h
free -h
uname -a
If this is a newly provisioned VPS, we recommend creating a cloud provider snapshot before installation. Snapshots are only suitable for quick rollback and are not the same as off-site backups; for the difference, see What's the Difference Between VPS Snapshots, Backups and Images.
The official 1Panel online installation documentation provides an interactive script. Log in to the server via SSH and run:
bash -c "$(curl -sSL https://resource.fit2cloud.com/1panel/package/v2/quick_start.sh)"
During installation you will be asked for the installation directory, port, security entrance, username and password. In production, do not use example passwords, and do not set the panel port to common ones like 8080, 8888 or 9000. After installation finishes, the terminal prints the access address in a format similar to:
http://服务器IP:面板端口/安全入口
If you need automated deployment, you can also use non-interactive mode. Below is a complete example of the official parameters; the password is for demonstration only, so replace it with a long random password in actual use:
PANEL_NON_INTERACTIVE=true \
PANEL_LANG=zh \
PANEL_INSTALL_DIR=/opt \
PANEL_PORT=18080 \
PANEL_ENTRANCE=panelEntrance \
PANEL_USERNAME=panelAdmin \
PANEL_PASSWORD='Replace_With_A_Strong_Password' \
PANEL_INSTALL_DOCKER=y \
PANEL_DOCKER_MODE=auto \
PANEL_CONFIGURE_ACCELERATOR=n \
PANEL_REPLACE_DAEMON_JSON=n \
bash -c "$(curl -sSL https://resource.fit2cloud.com/1panel/package/v2/quick_start.sh)"
If you don't want the password to appear directly in Shell history, prefer interactive installation, or inject the password in a one-off, protected automation environment. After installation completes, you can run the following command to view panel information:
1pctl user-info
If Docker installation fails, first check the Docker service and network separately; do not re-run the panel installation script to overwrite existing configuration.
Change the default port and security entrance in the panel settings. The security entrance is not a password; it acts as an extra gate on the URL path. After changing it, allow the new port in both the cloud provider security group and the system firewall, then close the old port.
Bind panel.example.com in the panel settings and request a Let's Encrypt certificate. Before requesting, confirm:
- DNS already resolves to the current VPS;
- Ports 80 and 443 are not occupied by other programs;
- The cloud security group allows 80/443;
- System time is accurate and the certificate tool can reach the public internet.
Once the panel domain's HTTPS works, configure separate subdomains for business apps. Do not let all apps share one management entrance, and do not expose the panel and database ports directly to the public internet.
Use root only for initialization and emergency repairs. For daily work, log in via SSH as a regular user and use sudo to run administrative commands. Allow only key-based SSH login and restrict the source IPs allowed to log in. The panel account should also use a separate password, not reused from your VPS, email or cloud provider account.
1Panel's app store is good for quick deployment, but "one-click install" still requires you to understand ports, persistent directories and environment variables. Before installing, confirm:
- Which ports the app needs;
- Which directories must be persisted;
- Whether the database is deployed separately;
- How to change the default account and password;
- Whether app upgrades include database migrations;
- Whether the official image and Compose file pin a version.
App containers can connect to databases over the internal Docker network; only 80/443 needed by the reverse proxy should be open to the public internet. The following ports usually should not be exposed publicly:
- MySQL
3306; - PostgreSQL
5432; - Redis
6379; - Docker Socket;
- The app backend's raw HTTP port;
- The management port used internally by the panel.
If an app must be publicly accessible, use 1Panel's website or reverse proxy feature to bind a domain and HTTPS, then point the upstream to the container's internal port. Remote database access should preferably go through an SSH tunnel or VPN; for detailed principles, see Don't Expose VPS Databases Directly to the Public Internet.
Site-building apps work best with a dedicated domain, dedicated database and dedicated storage directory. Do not let multiple sites share the same database administrator account, and do not put upload directories on the temporary container layer. Immediately after installation, complete:
- Changing the administrator username and password;
- Unifying the site URL with the HTTPS address;
- Scheduled database backups and file backups;
- Adjusting upload directory size and PHP execution time;
- Login protection, plugin updates and abnormal login alerts.
1Panel's app store includes several AI and automation tools, but the apps' own model provider keys, webhooks, databases and file directories are all production data. Put these apps under dedicated subdomains and set random paths or signature verification for webhooks. If you already have Ollama, Open WebUI or n8n deployment needs, you can treat 1Panel as the management layer, but do not write model API keys into public repositories or screenshots.
Backing up only Docker Volumes is not enough. At minimum, cover:
- 1Panel app configuration and Compose files;
- Database dumps;
- Docker Volumes and uploaded files;
- Domain, certificate and reverse proxy configuration;
.env, keys and recovery instructions;- Export files and version records of important tasks.
Do not put backups on the same disk as the production VPS. You can use S3-compatible object storage, another VPS or cloud drive, and keep multiple points in time. Set at least one combination of "daily incremental, weekly full, monthly long-term retention," depending on how fast the data changes.
A backup task showing success does not mean recovery will succeed. Every quarter, drill once in a test directory or temporary VPS: import the database, mount the Volume, restore environment variables, start the container, bind a test domain, and confirm login and key data are readable. For the recovery process, see VPS Backup and Recovery Drill Guide.
- Use a dedicated domain and HTTPS for the panel;
- Change the default port and security entrance;
- Use root only for initialization, and use keys for SSH;
- Open only 22, 80, 443 and ports actually needed by business in the cloud security group;
- Databases, Redis and Docker Socket do not listen on the public internet;
- Shut down unused apps and containers;
- Pin image versions; do not directly use
latestfrom unknown sources; - Enable system security updates and schedule maintenance windows;
- Set alerts for disk, memory, container restarts and certificate expiry;
- Save recovery credentials for the panel, databases and apps;
- Regularly review administrators, SSH Keys, API Tokens and webhooks;
- Copy backups off-site and run recovery drills.
First check whether DNS points to the correct IP, then check the cloud security group, firewall, 80/443 listeners and the reverse proxy upstream. Running the following command can first determine whether the app responds normally on the local machine:
curl -I http://127.0.0.1:应用端口
Check domain resolution, ports 80/443, Caddy/Nginx occupation, server time and DNS proxy status. If you use Cloudflare proxy, first confirm the DNS record and verification method meet the certificate tool's requirements.
In the panel's container logs, first look at the exit reason, then check environment variables, database connections, Volume permissions and memory. Don't just click "restart," or you can easily overwrite the real error logs. For general Docker troubleshooting, see What to Do When a VPS Docker Container Keeps Restarting.
First, do not delete the old container and Volume. Confirm that the Volume names, mount paths, database version and environment variables match between the old and new Compose, then restore from a snapshot or backup. Before upgrading, save the current image tag, configuration files and database dump.
| Option | Better suited for | Pros | Cons |
|---|---|---|---|
| 1Panel | People who want to manage hosts, Docker, websites and an app store | Complete single-server features, Chinese interface, continuously expanding app ecosystem | Still requires understanding Docker, networking and backups |
| Baota/aaPanel | Traditional PHP site building and panel-based operations | Mature website, PHP and database operations | Container and modern self-hosted app experience varies by version |
| Portainer | Users who only want to manage Docker containers and Stacks | Lightweight, clear Docker perspective | Does not handle the full host, certificate and site-building workflow |
If your core work is WordPress, PHP and traditional websites, Baota or aaPanel still works; if you want to manage Docker apps, databases, AI tools and sites, 1Panel's coverage is a better fit; if you already have separate Caddy/Nginx and a backup system and only lack Docker visual management, Portainer is lighter.
Individual users can start with Ubuntu 24.04, 2 cores, 4GB and 60GB NVMe, install 1Panel and Docker first, then deploy a low-risk test app. Once you've confirmed that domain, HTTPS, logs, backups and recovery all work, migrate your production website or database.
Don't treat 1Panel as a substitute for security and backups. Its most valuable aspect is consolidating repetitive single-server operations into one interface, giving you more time to focus on your business. Before going live, complete at least one drill of "recovering an app from a blank machine" — that matters more than installing a few extra apps.