Get GWS Backup running securely on your cPanel server in about twenty minutes.
This guide covers cPanel and Linux servers. Running it somewhere else? There is a Docker install guide and a Windows install guide — both are shorter, and none of the steps below apply to either.
You'll need four things:
-app.zip), the installer (-installer.php) and a README with these same instructions. Each is listed with a SHA-256 so you can check what you got.The app itself needs roughly 100 MB of disk and about 50 MB of RAM per client workspace. Your actual backup data is stored in your destination (Google Drive, S3, Azure or local disk) — not on the web server.
Never install GWS Backup inside public_html.
The application folder contains your encrypted credentials database and encryption keys. Those must never be web-accessible.
/home/youruser/gwsbackup ✓ correct
/home/youruser/public_html/backup ✗ never
Use a random subdomain name.
Give the installation an unguessable address — vault‑k7x93q.yourdomain.com rather than backup.yourdomain.com — and don't link to it from anywhere public.
Always use HTTPS. Run AutoSSL on the new subdomain before your first login so your admin password never travels in plain text.
On shared cPanel hosting there is nothing here for you to do — your host runs the firewall and its defaults already allow what the application needs. This section is for a VPS or a dedicated server, where the rules are yours.
Inbound: 443 to the web server, and nothing else.
Node listens on a local port — 3000 by default — and must only be reachable through your web server, never directly from the internet.
Outbound needs Google’s APIs, our licence server, whichever storage destination you have configured — and, up to v0.9613 only, SSH out to any Linux server you protect (Linux server backup was retired in v0.9700). The full list, with the reason for each entry, is on the requirements page.
If you filter outbound traffic by hostname, allow
googleusercontent.com as well as googleapis.com
— Drive serves the actual file content from there.
In cPanel → Domains → Create a New Domain (or Subdomains):
vault-k7x93q.yourdomain.compublic_html, e.g. /home/youruser/gwsbackup_webThen open SSL/TLS Status and run AutoSSL so the subdomain gets a certificate.
cPanel ships one of two tools for this — use whichever yours has. The settings are the same either way.
Whichever screen you are on, the values are:
gwsbackup (a folder in your home directory — not inside public_html)app.jsCreate or register the application, then stop it for now — there is nothing to run until the files are in place.
In File Manager, open the application root folder (e.g. /home/youruser/gwsbackup) and upload the -app.zip and -installer.php from your download. Then open the cPanel Terminal (or SSH) and run:
Use whichever version you downloaded. The wizard extracts the application and cleans up after itself. No terminal access? Use File Manager's Extract on the -app.zip instead, then delete the zip manually.
Back in Setup Node.js App (Route A) or Application Manager (Route B), add an environment variable so sign-in and Google callbacks return to the right address:
(your real subdomain, including https://).
Start the application. On first boot it generates its own keys and writes a complete
.env in the app folder, including the ENCRYPTION_KEY that
protects every credential it will ever store. Back that file up before you go
any further. Your recovery key is generated later, inside the app, and shown
to you on screen — nothing writes it to the server.
Visit https://your-random-subdomain/ in a browser:
That's it — set your backup schedule and destination in Settings and you're protected.
There should not be any memory issues — these are precautions, not fixes. Five minutes now buys you an installation that looks after itself.
In Setup Node.js App or Application Manager, add an
environment variable alongside NEXTAUTH_URL:
That caps Node’s heap at 2 GB — use 1024 on a small VPS.
Restart the app after adding it.
Check with free -h. If the swap line reads zero, add a swap file:
On shared cPanel hosting this is your host’s department — skip it.
A cron job that checks the console answers, and restarts it if not. In cPanel →
Cron Jobs, add this on a five-minute schedule
(*/5 * * * *), with your own subdomain and application folder:
If the console ever stops answering, Passenger restarts it on the next request. On a
plain VPS without Passenger, replace the touch with your service
manager’s restart command, e.g. systemctl restart gwsbackup.
Updates are one command, and your database is backed up automatically first:
-app.zip and its matching -installer.php into your existing application root (the folder containing gws-backup.db).The script backs up all your databases to db_backups/ first, then swaps in the new build. Your data, licence and settings are untouched. Finally, restart the app.
Once you've confirmed an update is stable, delete older archives from db_backups/ — they count against your hosting quota.
Inside your application root, treat these as crown jewels and keep your own offline copies:
.env — contains your ENCRYPTION_KEY. Without it, every credential stored in the app is permanently undecryptable..env; it
is the only way back into a locked-out account, because the app cannot send email.gws-backup.db — the console database: clients, encrypted credentials,
schedules, the job log and the audit log.clients/ — one database per client, holding that client’s backup
index. This is the bulk of your data.gws-backup-archive.db — present on older installations only. If it is
there, it counts.Migrating servers? Stop the app first, then move the whole application
folder and keep the same .env. Copy every database file together with its
-wal and -shm companions — never a .db on its own.
And your key may only be live on one installation at a time — retire
the old server when the new one goes live.
NEXTAUTH_URL is missing or wrong (step 4).Still stuck? Check the FAQ — it's searchable — or use the contact form (allow 1–2 days for free-edition support).