Is taking backups enough?

No. Until a restore from the backup has been tried at least once, nobody knows whether the backup works.

What access should we give the installer?

A time-limited project key or user with only the scope needed. Remove it when the work is done; do not share passwords.

Can several applications run on the same server?

Yes, but the gateway settings need a single owner; otherwise one service’s change can break another.

A script run that shows what it would do without changing anything. Its output is reviewed before approval.

Server setup checklist for logistics software: backups, monitoring, security

Whose job?

The server account, payment method and (for on-site installs) hardware belong to the company. The installer works with a restricted project key or time-limited access the company provides, and access is removed when the work is done. Passwords are not shared.

Before installing

Name one configuration owner: if several services run on the same server, one person or one process changes the gateway (for example reverse proxy) settings; the others leave requests.
List the domains and DNS records; plan SPF, DKIM and DMARC for email.
Classify the data to be processed: personal data, trade secrets, retention periods.
Decide where secrets (API keys, database passwords) live: a restricted file on the server or a secrets vault; never in the code repository.

During installation: dry run, approval, apply

Every change is first tried as a dry run (a run that shows what would happen without changing anything), then approved, then applied. This prevents writing to the wrong server or the wrong setting. Deletion and data migration steps are approved separately, with a backup taken first.

Backup and restore drill

Backups are kept off the server, in a different location.
Backups are encrypted, and the retention period is written down.
A restore is tried at least once: a fresh environment is built from the backup and the data is verified to be complete. A backup that has never been restored does not count.

Monitoring and alerts

Each service has a health endpoint that is checked regularly.
An availability check that runs outside the server, plus an alert email, is set up; the server cannot be the one to report that it is down.
Threshold alerts are defined for disk usage, memory and certificate expiry.

Security

Only the necessary ports are open; admin interfaces are closed to the outside and reached through a secure tunnel if needed.
Containers run as a non-admin user with a read-only file system where possible.
Secret scanning, dependency vulnerability scanning and container image scanning run regularly.
How long access logs are kept matches the privacy notice.

Mobile apps and devices

If a company-specific mobile app or handheld terminal is used: the app identity and signing key belong to the company. The key’s location, fingerprint and backup are recorded; losing the key means reinstalling every device. Device management (MDM, device owner) stays with the company’s IT.

After going live

A smoke test runs after every release: do the main pages, sign-in, critical flows and health endpoints really respond?
The rollback path is written down: the previous version’s tag and a one-command rollback step are ready before the release.
The release, the changed files and the result are logged, so it can later be found what changed and when.

Is the installation done? The verification report

The installation is handed over with a report in which every item has its evidence: which service runs which version, health checks, the result of the backup and restore test, open risks. The company sees what was done through this report and removes access.

Server setup checklist: before and after you install