Getting Started

Welcome to GWS Backup Support. This documentation will guide you through setting up your backup server and connecting your first Google Workspace client.

If you have questions about API limits, backup speeds, or "Stopped" statuses, please review our Frequently Asked Questions.

Support is free, and stays free for as long as we can manage it — on the free ten-workspace licence as much as on any other. Email support@gwsbackup.com and a person reads it. Early adopters get particular attention: if you took a chance on this before it had a track record, that earns you more of our time, not less.

Minimum specs & requirements

Read this before you start: two of the items below stop the application dead if they are missing, and it is much less annoying to find out now.

The two hard requirements

  • Node.js 22.5 or newer. Not a preference — GWS Backup uses the SQLite engine built into Node 22, so it will not start at all on Node 20 or older. On cPanel this is whatever versions your host offers in Setup Node.js App; if the newest on offer is Node 20, the application cannot run there and no amount of configuration will change that.
  • Your licence key. The software stays locked on the activation screen until a valid key is entered, and activating needs an internet connection. Keys are issued personally for now — request one here, usually answered within 1–2 days.

Server

  • Memory: roughly 50 MB of RAM per client workspace you back up, plus a little headroom for the application itself.
  • CPU: 1–2 vCPU cores is enough for the engine and its parallel workers. Backups are limited by Google’s API rate limits far more than by your processor.
  • Disk: about 100 MB for the application, plus room for its index database, which grows with the number of files you protect. Your actual backup data lives in your destination — Google Drive, S3-compatible, Azure or a local disk — not on this server.
  • Outbound HTTPS to Google’s APIs and to our licence server. No inbound ports need opening beyond the web server itself — the full list is under Network & firewall below.
  • HTTPS on the console. Run AutoSSL (or your own certificate) on the subdomain before you log in for the first time.

Network & firewall

GWS Backup needs a great deal of outbound access and almost no inbound. Getting that asymmetry right is most of what securing an installation amounts to.

Outbound — all of this has to be allowed

DestinationPortWhat stops working without it
*.googleapis.com
accounts.google.com
*.googleusercontent.com
443 TCP Everything to do with the workspaces you protect — Drive, Gmail, the Admin SDK, OAuth tokens, and the file transfers themselves.
Our licence server
licensingpki342o2889dsf.kikosolutions.co.uk
443 TCP Activation and its periodic re-check. Product news in the console arrives on the same reply, so there is no second address to allow.
Your S3 endpoint — s3.<region>.amazonaws.com, Wasabi, Backblaze, MinIO and so on 443 TCP Only if one of your destinations is S3-compatible storage.
<account>.blob.core.windows.net 443 TCP Only if one of your destinations is Azure.
Each Linux server you protect 22 TCP, or the port set on that server Linux server backup connects out over SSH. Nothing ever connects in.
Your DNS resolver, and a time source 53, and 123 UDP The licence is a signed token with a validity window. A clock several minutes out makes activation fail in a way that reads as a network fault.

If you filter outbound traffic by hostname, do not stop at googleapis.com. Drive hands the actual file content over on googleusercontent.com. A rule allowing only the API host lets every listing and every permission check succeed, then fails at the moment bytes move — which shows up as intermittent backup failures rather than as anything to do with your firewall.

Inbound — keep it as small as you can

  • The console’s own port, and nothing else. Restrict it to where you actually administer from — an office address, a VPN range — rather than to the whole internet.
  • Hosted server: 443 to the web server only. Node listens on a local port (3000 by default) and Passenger or your proxy reaches it over loopback. If that port is reachable from outside, it bypasses your web server, your TLS and any address restriction you put there.
  • Docker: publish only to the interface you need. If something else terminates TLS in front of it, publish as 127.0.0.1:3000:3000 so the container is not on the network at all.
  • Windows: the installer creates the rule for you — inbound on the console’s port, private profile only — and removes it when you uninstall. Normally 3000; if that was taken at setup time the installer chose a free port and the rule follows it. You will never see Windows ask, because the application runs as SYSTEM in session 0 and cannot put a dialog on anyone’s desktop. Left to itself Windows silently blocks it, while loopback carries on working and hides the problem until another machine tries to connect.

What it never needs — do not open these

  • Nothing inbound from Google. The application always initiates. Even the OAuth callback comes back through your browser, not from Google’s servers, so there is no rule to add for it.
  • Nothing inbound from us. We never connect to your installation, for support or for anything else.
  • No SMTP. The product sends no email at all — which is also why the recovery key it shows you at setup matters so much.

PHP — only for the updater

The application itself is Node.js and does not use PHP at all. PHP is needed for one thing: the installer script that unpacks a release and backs up your database before it does. If you would rather extract the zip by hand in File Manager, you do not need PHP at all.

  • Any PHP 8.x with the ZipArchive extension enabled (standard on cPanel). The script deliberately avoids newer-only syntax, so it is not fussy about the minor version.
  • If you get the choice, pick PHP 8.3: 8.1 is already end of life and 8.2 reaches it in December 2026.

Google Workspace side

  • Super Admin access to the workspace you want to protect, to authorise domain-wide delegation.
  • A Google Cloud service account with the required API scopes. The in-app Connection Wizard gives you the exact scopes to paste — you do not need to work them out.

Installation

One package, one supported route today. Everything below describes what actually exists — where something is still being built, it says so rather than pretending otherwise.

cPanel / shared hosting — the tested route

The easiest way to run GWS Backup 24/7 without administering a server, and the path every current installation uses. If your host offers cPanel with Setup Node.js App or Application Manager running Node 22.5+, you can be up in about twenty minutes.

Two rules that matter more than any of the steps:

  • Install outside public_html. The application folder holds your encrypted credentials database, your .env keys and your recovery key. Under the web root, one misconfiguration puts all three within reach of anyone on the internet.
  • Serve it on a randomly-named subdomain — something like vault-k7x93q.yourdomain.com, not backup.yourdomain.com. Bots scan the obvious names looking for admin panels.

In outline: create the subdomain and run AutoSSL, create the Node.js application pointing at app.js, upload the release zip and its matching installer to the application root, run the installer, set NEXTAUTH_URL to your full https:// address, then start the app and complete setup in the browser.

Unpacking is one line in cPanel’s Terminal (or over SSH), from the application root:

cd ~/gwsbackup
php gwsbackup-cpanel-0.9611-installer.php

That script backs up your existing database before it extracts anything, then removes itself and the zip. If your host gives you no terminal, use File Manager’s Extract on the release zip instead and delete both files afterwards — the result is the same, minus the automatic database backup.

→ Follow the full step-by-step cPanel install guide

A plain Linux server

The download is the same package: a self-contained Node application whose entry point is app.js. On a VPS you would unpack it outside your web root, set NEXTAUTH_URL (and PORT if you are not proxying), run it under a process manager such as systemd, and put a reverse proxy with TLS in front.

We have not yet published step-by-step commands for this, deliberately. Every installation to date runs under cPanel/Passenger, so a bare-VPS walkthrough would be instructions we have not followed ourselves end to end. It is being written and tested now. If you want to deploy this way before then, get in touch — we will walk you through it personally and your notes will shape the guide.

Docker

Ships with the 2 September release, alongside cPanel. The image carries its own Node runtime, so there is nothing to install first and no version to check — two files, two generated secrets, and docker compose up -d. Your databases live in a Docker volume, so updating replaces the container and leaves them alone.

→ Follow the full step-by-step Docker install guide

Release notes

Every version, what changed in it, and which builds carry it — read the release notes. Previous versions stay downloadable from the download page under Previous versions in each platform.

Windows

Ships with the 2 September release, alongside cPanel and Docker. One installer, no terminal work: it carries its own Node.js runtime and registers GWS Backup to start with Windows before anyone signs in, so a machine that reboots overnight carries on backing up instead of waiting at the lock screen.

Windows 10, Windows 11 or Server 2016 and newer, 64-bit. The installer is not yet code-signed, so Windows will warn about an unrecognised publisher — the guide explains what to check instead.

→ Follow the full step-by-step Windows install guide