Use cases

Situation

Nordlicht runs a warehouse-management platform that must remain available across three shifts. Prior to engagement, alerting was limited to a hosting-provider dashboard, PostgreSQL backups were untested, and a disk-full event on a Saturday night halted goods-out for 3 hours 40 minutes. The internal IT team of four could not staff nights or weekends.

Environment

Region and placement

eu-central-1 (Frankfurt) with a warm standby in eu-west-1

Hosts

8 production VMs (application, PostgreSQL primary/replica, Redis, jump host, reporting)

Operating systems and runtime

Ubuntu 22.04 LTS; PostgreSQL 15; Redis 7

Data stores

2.4 TB warehouse and customs data; 380 GB nightly change volume

Connectivity and access

Site-to-site IPsec from the Hamburg DC to the cloud VPC; no public database endpoints

Agreed scope

• 24/7 uptime monitoring on all eight nodes and the VPN tunnels
• Daily encrypted backups of PostgreSQL with quarterly restore tests
• Query and index review of the goods-out and inventory schemas
• Security baseline: SSH key-only access, fail2ban, unattended-upgrades, UFW

Work performed

• Deployed Prometheus exporters and Alertmanager with PagerDuty routing to Veltis on-call.
• Implemented pgBackRest to object storage with AES-256, 14-day retention, and a documented restore runbook.
• Added missing indexes on shipment_events and stock_moves; reduced p95 goods-out query time from 1.8 s to 210 ms.
• Closed inbound 5432/6379 from the public internet; restricted admin access to the jump host and a named engineer group.
• Ran a full restore drill on 12 March 2026; recovered the primary to a staging host in 47 minutes.

Measured results

Situation

Clinic practice-management and imaging systems were hosted on ageing on-premises servers with local USB backups. A ransomware incident at a peer practice in 2025 prompted the medical director to require off-site encrypted copies, patch evidence, and a 24/7 contact for outages that stop chair-side work. Data is special-category personal data under GDPR Article 9.

Environment

Region and placement

Private cloud in Nuremberg plus encrypted off-site replica in Frankfurt

Hosts

6 servers (practice management, DICOM imaging, file, domain, backup, jump)

Operating systems and runtime

Windows Server 2022; Debian 12 for the backup target

Data stores

9.1 TB imaging; 420 GB practice-management database (SQL Server 2019)

Connectivity and access

Site-to-site VPN from each clinic; MFA on administrative access; no direct RDP from the internet

Agreed scope

• Named infrastructure engineer and 24/7 telephone support for P1 clinic outages
• Encrypted daily backups with a 30-day retention and monthly restore evidence
• Patch windows aligned to clinic closing hours (Tue 21:00–23:00 CET)
• Hardening: Credential Guard, restricted RDP, application allow-listing on the imaging host
• Written processing record to support the client's GDPR Article 28 documentation

Work performed

• Moved backups from USB to an isolated Debian target with restic, repository encryption, and immutable 7-day snapshots.
• Disabled internet-facing RDP; introduced a jump host with hardware-key MFA for Veltis and client administrators.
• Applied outstanding cumulative updates; established a monthly change calendar signed off by the practice IT lead.
• Documented restore of a single clinic's SQL database in 28 minutes during the April 2026 drill.
• Issued quarterly configuration and patch reports used in the group's insurer questionnaire.

Measured results

Situation

The manufacturing execution system runs on one Windows application server. When the C: volume filled during a weekend job, operators could not close work orders until Monday. There was no on-call rota. Management required a low-scope, low-cost control plane rather than a full cluster rebuild.

Environment

Region and placement

On-premises VMware cluster; Veltis manages the guest OS and application layer

Hosts

1 production MES application server (plus a Veeam backup proxy already operated by plant IT)

Operating systems and runtime

Windows Server 2019; SQL Server Express on the same host

Data stores

180 GB application and SQL data

Connectivity and access

Plant LAN only; Veltis access via a monitored jump host after plant-IT approval

Agreed scope

• Uptime and disk monitoring with SMS/email to plant IT and Veltis
• Weekly application-consistent backups coordinated with the existing Veeam job
• Monthly OS and SQL Express patching in the Sunday maintenance window
• Email support with a 48-hour response SLA

Work performed

• Installed disk, service, and SQL Express checks; alert at 75% and 90% volume utilisation.
• Documented a restore path using the plant's Veeam repository; completed a file-level restore test in 19 minutes.
• Applied outstanding Windows and SQL Express updates during two Sunday windows with a written rollback note.
• Added a 50 GB volume and log-rotation policy so the original disk-full condition cannot recur under normal load.

Measured results

Situation

Ledgerhaus sells to Steuerberater practices and needed SOC 2 Type I evidence in Q2 2026 for a bank-channel partnership. The application was stable, but slow reporting queries blocked the primary, backups had never been restored, and there was no named owner for access reviews or patch evidence.

Environment

Region and placement

Managed Kubernetes and PostgreSQL in eu-central-1; object storage in eu-central-1

Hosts

12 worker nodes; 1 PostgreSQL primary + 1 synchronous replica; 3 Redis nodes

Operating systems and runtime

Bottlerocket on EKS; PostgreSQL 16 on RDS-equivalent managed instances operated by Veltis

Data stores

1.1 TB tenant data; 90 GB daily WAL

Connectivity and access

Private link from the application VPC; GitHub OIDC to the cluster; no standing human SSH

Agreed scope

• Named engineer, custom SLA, and 24/7 incident telephone
• Database performance programme and capacity plan through 2027
• Daily backups, point-in-time recovery window of 7 days, quarterly restore evidence
• Access reviews, CIS-aligned node hardening, and evidence folders for the SOC 2 auditor

Work performed

• Identified three reporting queries without tenant_id predicates; added covering indexes and a read replica for BI.
• Primary CPU p95 fell from 84% to 31% during month-end close; statement timeout policy introduced at 30 s.
• Configured continuous WAL archiving and ran a PITR drill to a forked instance (restore to 16:40 CET, 22 minutes).
• Removed long-lived cloud keys; engineers assume roles via OIDC with 4-hour sessions and a ticket ID in the audit trail.
• Delivered the infrastructure evidence pack (access, change, backup, incident) used in the June 2026 SOC 2 Type I report.

Measured results

Situation

Checkout latency and a 14-minute database lock during Black Friday 2025 caused abandoned carts. The merchant calendar required a documented capacity and backup posture before the next campaign, without replacing the Shopware stack.

Environment

Region and placement

eu-central-1; CDN at the edge for static assets

Hosts

6 application nodes, 2 MySQL 8 (primary/replica), 2 Elasticsearch, 1 Redis, 1 worker

Operating systems and runtime

Debian 12; MySQL 8.0; Shopware 6.6

Data stores

640 GB catalogue and order data; object storage for media

Connectivity and access

Public HTTPS via load balancer; databases on private subnets; admin via VPN

Agreed scope

• Daily backup architecture with order-table restore tested before campaign freeze
• MySQL slow-query review and replica use for catalogue search refresh
• 24/7 monitoring through the campaign window with a 24-hour standard SLA thereafter
• Security hardening of admin endpoints and SSH

Work performed

• Moved catalogue reindex off the primary; replica lag stayed under 2 s at 4× baseline traffic in a load test.
• Added covering indexes on order_line and customer_address; checkout p95 fell from 1.4 s to 340 ms in staging replay.
• Configured Percona XtraBackup nightly plus binlog shipping; restored 50,000 orders to staging in 36 minutes.
• Restricted /admin to VPN; rotated leaked staging credentials found in a leftover .env on a worker host.
• Staffed an enhanced watch from 24–30 November 2026 campaign week under the existing Professional contract.

Measured results

Situation

Billing runs and smart-meter head-end software sit on a small estate that cannot fail during winter load. Internal IT is shared with the municipal shareholder and is not staffed after 17:00. A failed tape rotation in 2025 left a six-day backup gap that the supervisory board required to be closed with off-site, tested copies and a named vendor SLA.

Environment

Region and placement

Customer data centre in Rosenheim; replica in a Munich colocation facility

Hosts

9 guests (head-end, billing, Oracle-compatible DB, file, jump, monitoring, three utility services)

Operating systems and runtime

RHEL 8 and 9; PostgreSQL 14 (migrated from a legacy engine in 2024 by a third party)

Data stores

3.6 TB metering and billing; regulatory retention 10 years on archive volumes

Connectivity and access

Air-gapped OT network is out of scope; Veltis manages IT-side guests only, via a dual-control jump host

Agreed scope

• Named engineer, custom winter-season SLA, 24/7 P1 telephone
• Daily backups to Munich colo with monthly restore evidence to the board pack
• CIS RHEL hardening except where vendor software requires documented exceptions
• Patch orchestration with a change advisory note to the client's IT security officer

Work performed

• Replaced tape-only backups with Borg to the Munich colo, encrypted, with a 30-day operational window and yearly archive to WORM storage operated by the client.
• Closed the six-day coverage gap; the longest backup interval is now 24 hours.
• Applied RHEL STIG-informed controls; eight vendor exceptions logged with expiry dates.
• Established dual-control for production: Veltis engineer plus client operator on the jump host for schema changes.
• Completed a billing-database restore to isolated hardware in 1 hour 12 minutes (May 2026 board evidence).

Measured results