On-Premise System Requirements

Prepare your server for a Zuar Portal on-premise installation by completing the steps below. When all requirements are met, run the requirements check script and contact Zuar Support for the install command. For the installation steps that follow, see On-Premise Installation Instructions.

1. Server Requirements

Resource	Minimum
OS	Ubuntu 22.04 LTS (Jammy)
CPU	2 vCPU
RAM	4 GB
Disk	80 GB
Architecture	x86_64 (amd64)

Verify

lsb_release -d
# Expected: Ubuntu 22.04.x LTS

uname -m
# Expected: x86_64

nproc
# Expected: 2 or more

free -h
# Expected: 4 GB or more total

df -h /
# Expected: 80 GB or more available

2. User Setup

Create a user with UID 1000 and passwordless sudo. The username can be anything — we use <deploy-user> as a placeholder below. Zuar will use the actual name in the install command.

Why UID 1000? Portal containers run internal processes as UID 1000. Docker volume mounts share file ownership between host and container. If the host user has a different UID, the application will fail with permission errors on SSL certificates, application data, and configuration directories.

Create the User

# As root:
useradd -m -s /bin/bash -u 1000 <deploy-user>
passwd <deploy-user>
# Set a password for SSH access.

Configure Passwordless Sudo

echo "<deploy-user> ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/<deploy-user>
chmod 440 /etc/sudoers.d/<deploy-user>

Configure SSH Access for Zuar Support

Zuar Support requires SSH access to install and maintain the portal. Add the public key provided by your Zuar contact:

mkdir -p /home/<deploy-user>/.ssh
echo "<PUBLIC_KEY_PROVIDED_BY_ZUAR>" >> /home/<deploy-user>/.ssh/authorized_keys
chown -R <deploy-user>:<deploy-user> /home/<deploy-user>/.ssh
chmod 700 /home/<deploy-user>/.ssh
chmod 600 /home/<deploy-user>/.ssh/authorized_keys

Verify

id <deploy-user>
# Expected: uid=1000(<deploy-user>) gid=1000(<deploy-user>) groups=1000(<deploy-user>),sudo

sudo -u <deploy-user> sudo whoami
# Expected: root

ssh <deploy-user>@localhost whoami
# Expected: <deploy-user>

3. Firewall — Inbound Ports

Open the following ports for inbound traffic:

Port	Protocol	Purpose
22	TCP	SSH — installation and ongoing support
80	TCP	HTTP — redirects to HTTPS
443	TCP	HTTPS — Portal application

4. TLS Certificate (Optional)

The portal serves over HTTPS. By default it uses a self-signed certificate — HTTPS works, but browsers show an "untrusted certificate" warning. For production deployments, supply your own CA-signed certificate.

If a customer-supplied certificate is needed, the install command will include the --tls-cert flag. Without that flag the server uses the self-signed certificate and this section can be skipped.

Required Files

Place the following files on the server before running the install script:

File	Description
`/home/<deploy-user>/portal-cert/fullchain.pem`	Full certificate chain (server cert + intermediates)
`/home/<deploy-user>/portal-cert/privkey.pem`	Private key, PEM format, no passphrase

Set ownership and permissions:

chmod 600 /home/<deploy-user>/portal-cert/privkey.pem
chmod 644 /home/<deploy-user>/portal-cert/fullchain.pem
chown -R <deploy-user>:<deploy-user> /home/<deploy-user>/portal-cert

Verify

# Certificate is valid:
openssl x509 -in /home/<deploy-user>/portal-cert/fullchain.pem -noout -dates

# Private key matches the certificate (no output means matching modulus):
diff <(openssl x509 -in /home/<deploy-user>/portal-cert/fullchain.pem -noout -modulus) \
     <(openssl rsa -in /home/<deploy-user>/portal-cert/privkey.pem -noout -modulus)

Notes: - Self-signed certificates are accepted, but browsers will show a warning. - If the certificate covers multiple domains (SAN), all of them must resolve to this server. - Expired certificates will block HTTPS access — monitor expiration dates.

5. Outbound Network Access

The server must be able to reach the following destinations during installation and at runtime. If your environment restricts outbound traffic, add these to your allowlist.

Installation and Package Repositories

Destination	Port	Purpose
github.com	22, 443	Clone the `portal-docker-setup` repository
download.docker.com	443	Docker APT repository
apt.releases.hashicorp.com	443	HashiCorp Vault APT repository
packages.microsoft.com	443	MSSQL tools and ODBC drivers
awscli.amazonaws.com	443	AWS CLI installer
astral.sh	443	Python tooling (uv)

Runtime Services

Destination	Port	Purpose
`575296055612.dkr.ecr.us-east-1.amazonaws.com`	443	Pull Docker images (AWS ECR)
`*.amazonaws.com`	443	Database backup downloads (S3)
licensing3.zuarbase.net	443	License validation
vault.zuarbase.net	8200	Vault AppRole authentication, AWS STS credentials
devpi.zuarbase.net	443	Python packages (plugins)
acme-v02.api.letsencrypt.org	443	SSL certificate issuance (if using Let's Encrypt)

Verify

for host in github.com 575296055612.dkr.ecr.us-east-1.amazonaws.com vault.zuarbase.net:8200 download.docker.com apt.releases.hashicorp.com awscli.amazonaws.com packages.microsoft.com astral.sh licensing3.zuarbase.net; do
  code=$(curl -s --connect-timeout 5 -o /dev/null -w "%{http_code}" "https://$host")
  printf "  %-55s %s\n" "$host" "$code"
done

# Any 2xx, 3xx, or 4xx response means the host is reachable.
# A 000 response means the connection is blocked.

# Test SSH to GitHub (port 22):
ssh -T git@github.com 2>&1 | head -1
# Expected: "Hi ...! You've successfully authenticated" or "Permission denied"
# Either response confirms github.com:22 is reachable.

Note: If outbound access is restricted by policy, Zuar can provide a VPN tunnel as an alternative. Contact your Zuar representative for details.

6. DNS (Custom Domain)

If the portal will be accessible at a custom domain (e.g., portal.yourcompany.com):

Create a DNS A record pointing the domain to the server's public IP address.
Allow time for DNS propagation before installation.

Verify

dig +short portal.yourcompany.com
# Expected: your server's public IP address

7. Software Prerequisites

The installation script automatically installs all required software, including Docker, Docker Compose, Git, HashiCorp Vault, and the AWS CLI. No manual package installation is needed.

The following packages are expected to be present on a standard Ubuntu Server installation and are used before the install script runs:

Package	Used For
curl	Connectivity checks, package key downloads
wget	File downloads
openssl	Secret generation
gpg	APT signing key imports
ssh / ssh-keyscan	Repository access
sudo	Privileged operations
tar / gzip	Archive extraction
lsb_release	OS version detection

These are included by default on Ubuntu 22.04 Server. If your base image has been stripped down, ensure they are installed before proceeding.

8. Run the Requirements Check Script

Before requesting an install command, run the requirements check script to confirm the server meets all prerequisites:

curl -sL https://raw.githubusercontent.com/zuarbase/portal-on-prem-installer/main/check-requirements.sh | sudo bash -s -- --user <deploy-user>

If you are supplying a TLS certificate (step 4), add the --tls-cert flag:

curl -sL https://raw.githubusercontent.com/zuarbase/portal-on-prem-installer/main/check-requirements.sh | sudo bash -s -- --user <deploy-user> --tls-cert

The script checks: OS version, CPU/RAM/disk, the deploy user (UID 1000, passwordless sudo), pre-installed system packages, TLS certificate (if required), and outbound connectivity. All checks must pass before Zuar can schedule your installation.

Pre-Installation Checklist

Ubuntu 22.04 LTS, x86_64, with at least 2 vCPU / 4 GB RAM / 80 GB disk
Deploy user exists with UID 1000 and passwordless sudo
Zuar Support SSH public key added to the deploy user
Inbound ports open: 22, 80, 443
TLS certificate in place (only if using a customer-supplied certificate)
Outbound access confirmed to all required destinations
DNS A record configured (if using a custom domain)
check-requirements.sh passes with no errors

Once every item is confirmed, continue to the On-Premise Installation Instructions and contact Zuar Support to schedule your installation.