The automatic way: a single script from your account prepares the entire server (Apache + PHP web stack, database, security tools, cron). After that — deploy the dashboard, issue an SSL certificate and enter your license. Works on Ubuntu/Debian: on a fresh VPS it sets everything up from scratch, on an already-configured server it acts additively only (the "Configured server" profile, step 01). All the commands below are in order — just scroll from top to bottom. On a fresh VPS every step applies one after another; if the server is already configured or runs a hosting panel, the script deliberately leaves part of the work to you — it states exactly what at the end of its run (how to read that output — in step 01).
monitor.example.com — your domain; 203.0.113.10 — the server's real IP; /var/www/monitor — the dashboard root (where public/, assets/ and config.php live); choose your own database password.
jail.local), the root crontab, UFW rules, the Apache config. If the server is already configured (a working dashboard, sites, mail, your own jails), choose the "Configured server" profile: it makes only additive changes and leaves your firewall, Fail2ban, mail, SSH and sysctl untouched. When a hosting panel is detected, the script switches to this mode on its own. Before the first run you can enable a dry run (a checkbox in your account) — it shows what would be done without changing anything. On a live server, take a snapshot just in case.
my.arciveo.com → the "Server setup" section (available after you subscribe to Arcivéo Security Monitor). It is tied to your account and contains a personal token.
The script provisions the whole server: the web stack (Apache + PHP), the database, SSL tools, the full set of security tools and cron jobs (Lynis, SMART, debsums, Logwatch, a daily report, ipsum updates).
1) Choose a protection level (in your account, before copying the command):
2) Run the command from your account on the server as root — it looks like this:
3) Read the output at the end — it says what is left for you to do. The script finishes with a block of checks and a “Next — install the panel” list. Some steps it deliberately does not perform: which ones depends on the chosen profile and on what it found on the server. Compare with the list below — you only need to do the items whose lines actually appeared in your output.
Control panel detected (…) — the site is created with the hosting panel's own tools, the script does not build a vhost. Step 03, the “Server with a hosting panel” branch.No vhost created (no domain given) — the “Configured server” profile without a domain: a vhost with no name would become the default site and would intercept your own sites, so it was not created. Step 03, the “Create the vhost manually” branch.sudo rules NOT written — the script could not determine which account the panel runs under. This is a normal situation: the panel files are uploaded after auto-setup, so there was nothing to detect yet. Without these rules the modules will not see system data. Step 04, the “sudo for the web server” block.! Nginx does not read .htaccess — Nginx sits in front of Apache, and writing the deny rules into its config automatically did not work out. Be sure to do this: otherwise data/, keys/, database/ and config.php are served to the outside, bypassing .htaccess. Step 03, the “If Nginx sits in front of Apache” block.UFW installed but inactive — the firewall is installed but switched off: on a configured server the script does not enable it by itself so as not to cut off your access. Enable it yourself, making sure to allow your SSH port:
Fail2ban installed but not running — start it: sudo systemctl enable --now fail2ban.Database server present … but not running — start the DBMS before step 04: sudo systemctl enable --now mariadb (or mysql — depending on what is installed).Certbot skipped — issue SSL in … — the certificate is issued with the Let's Encrypt switch in the hosting panel; you do not need step 06.All checks passed. Items marked with ! need attention; the details go into the log, whose path the script prints at the very end (Log: …).
To open the dashboard at an address like monitor.example.com and get a free SSL, the domain must point to the server. In the DNS control panel (at your registrar or host), create an A record:
After a few minutes (sometimes up to an hour), check that the domain points to the server:
/var/www/monitor and configured the Apache site (DocumentRoot at the panel root, PHP-FPM, AllowOverride for .htaccess). In the script output this is the vhost … → DocumentRoot … line. There's no need to create the directory and vhost separately — just upload the files and set permissions.
The “Server with a hosting panel” branch (in the output: Control panel detected (…)). On such a server the sites are managed by the panel, and the script deliberately does not create its own vhost — it would be wiped the first time the panel rebuilds its configs. The order is as follows:
public_html: next to index.php, api/ and assets/ there must also be the internal config.php, includes/, data/, tmp/, logs/, keys/, cron/ and database/. Nothing needs to be moved above the web root: the internal folders are closed off by the .htaccess shipped with the distribution, and under Nginx by the deny rules the script wrote into the domain's config.config.php (step 05). In the commands, replace the paths with /home/account/web/domain/public_html, and the owner with that domain's user instead of www-data.The “Create the vhost manually” branch (in the output: No vhost created (no domain given)). This only happens with the “Configured server” profile when no domain was passed. The easiest way is simply to re-run the command from your account, specifying the domain:
Re-running is safe: what is already done is not duplicated. If you do need to create the vhost by hand — here is the same config the installer writes:
ServerName here is mandatory. A vhost with no name becomes Apache's default site and starts answering for other domains on the same server. For the same reason, do not disable 000-default.conf on a configured server: that site may have been repurposed for someone's live project — on a fresh VPS the installer removes it itself, here you should not.
! Nginx does not read .htaccess). Nginx serves static files straight from disk and does not read .htaccess — the internal folders end up exposed to the outside, even though Apache closes them correctly. The script has prepared a file with the deny rules in advance; it needs to be included in your site's server{} block, after which Nginx must be reloaded:
my.arciveo.com → "Downloads". Unpack the archive before uploading it to the server.
Upload the distribution contents to /var/www/monitor (so that public/, assets/, config.php etc. end up inside) — via SFTP/SCP (FileZilla / WinSCP) or with the scp command from your local computer:
ServerName), pass it to the auto-setup command back in step 01: … | sudo bash -s -- monitor.example.com (or enter the domain in the "Panel domain" field in your account). If no domain is passed, the panel responds on any host and by IP, and certbot will write the ServerName when issuing the SSL (step 06); nothing needs to be reinstalled.
root or via SFTP, the files belong to root, and the web server (www-data) won't be able to read them — the panel will open blank or with a 403 error (in the log: .htaccess unreadable / directory not executable). The command below fixes it:
Open up SFTP uploads for yourself. After the command above all files belong to www-data, while FileZilla / WinSCP connect as your own user — an upload will fail with SSH_FX_PERMISSION_DENIED (Permission denied). Choose one of the two options.
Option A — an ACL for your user only (recommended). Write access goes to you alone; the web server still cannot overwrite the panel code:
Option B — via the www-data group. Simpler, but the web server gets write access to the panel files as well: with a vulnerability in PHP the code could be replaced. The order of the commands matters — config.php and the working folders are locked down last:
id deploy — www-data must appear in the group list; ls -ld /var/www/monitor — permissions drwxrwsr-x, where the letter s instead of x means setgid is set.
Create the database and user, then import the schema. Paste the DB block into the terminal as a whole (sudo mysql logs in as root over the unix socket — no root password needed). monitor_db and monitor_user are example names; you can set any of your own. Remember the database name, user and password — you'll enter them in config.php in the next step:
admin account itself on the first browser visit (from database/db.sql) if the database is empty.
If the tables were not created (the panel shows a database connection error or a blank screen instead of the login form) — import the schema manually. The command is run in the panel root, the values are taken from the block above:
$DBNAME / $DBUSER / $DBPASS variables have already been “forgotten” (a new terminal session), put the values into the command by hand or set them again with the same three lines from the block above.
sudo rules NOT written, there was nothing to detect the panel account from (the files were not uploaded yet), and the rules were not created. Without them, sections such as the firewall, Fail2ban and CrowdSec will stay empty. Now that the files are in place, run the command from your account once more, naming the account explicitly:
www-data with the user your site's PHP runs under (on a hosting panel this is usually the domain owner). You can look it up like this:
/etc/sudoers.d/monitor exists and contains lines with your user.
config.php in the panel root (/var/www/monitor/config.php) is the only file you need to edit by hand. All panel settings are defined in it as define() constants. Open it in an editor:
Fill in your own values in the highlighted spots; leave the rest as is:
What to change:
DB_NAME, DB_USER, DB_PASS — exactly the same database name, user and password you set when creating the DB in step 04 (if you kept the examples — monitor_db / monitor_user). Do not touch DB_HOST and DB_CHARSET.APP_URL — the full panel address with https://, no trailing slash and no www. It must match the domain you activate the license on (step 07), otherwise the key will be rejected.TIMEZONE — your timezone (list — timedatectl list-timezones). It only affects how the panel displays dates; it does not affect when cron jobs run (the system timezone applies there).SESSION_LIFETIME — after how many seconds of inactivity the panel asks you to log in again (default 8 hours). E.g. 3600 = 1 hour, 86400 = 1 day.display_errors, log_errors, error_log) — leave at the defaults.Save the file (Ctrl+O, Enter, then Ctrl+X) and restart PHP-FPM — otherwise the changes won't apply because of OPcache:
640 permissions (set in step 03) and an explicit deny in the root .htaccess. Do not publish it to public repositories or send it to support with the real password.
http://.
Certbot skipped — issue SSL in …). The certificate is issued with the Let's Encrypt switch on the web domain in the panel itself — that way the panel also takes care of renewing it.
certbot and the Apache plugin are already installed by auto-setup. Your domain's DNS should already point to the server (step 02). Issue it in one command:
If the panel must also open with www., list both names in a single command, otherwise the browser will show a certificate warning on the second address:
Y.<VirtualHost *:443>, sets up the http→https redirect and auto-renewal. At the end — Successfully enabled HTTPS.
dig +short monitor.example.com returns the server's IP and that ports 80/443 are open (sudo ufw allow 80,443/tcp).
After issuing: https://monitor.example.com opens with a padlock, and http:// redirects to https://.
Open https://monitor.example.com, sign in with admin / useradmin and go through the checklist:
ARCIVEO-… activation code from your account for your domain and paste the key into “Settings” → “License”. Learn more.public/start_db.php if it is still there: it lets anyone recreate the database without authorization. As long as the file sits in the dashboard root or in public/, the dashboard warns about it with a red banner.sudo /usr/local/bin/clamav-scan.sh) puts a heavy load on the disk and CPU and can take an hour or more — on a live server it is better to wait for the nightly run at 01:30. The “Disks (SMART)”, “Performance” and “Security updates” sections fill up on their own: every 30 minutes, every 5 minutes and once an hour respectively.