Support & Documentation

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.
• HTTPS on the console. Run AutoSSL (or your own certificate) on the subdomain before you log in for the first time.

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:

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

Windows

Built and in testing, and not released yet. There is no installer to download today — when there is, it will be announced in the news section and inside the app itself. We would rather be late than hand you an installer that eats an afternoon.