Engineering
Design, migration and automation — with ownership of the outcome
Network, datacenter, cloud and software engineering. Every project starts with an audit and ends with documentation and handover.
The problem
The project ended; ownership of the result never began
The integrator builds it, signs the acceptance note and leaves. What stays behind is a configuration nobody can explain, a diagram that was accurate a year ago, and a team that avoids changes because it cannot predict what a change will touch. The next project gets built on top of that layer.
- Design decisions were never written down
- Every change runs in production for the first time
- The vendor is chosen by habit rather than by requirements
- Handover means an archive, not knowledge
What we deliver
Design, migration and automation — with ownership of the outcome
Audit and current state
Topology, configurations, SPOFs, licences and technical debt in one prioritised document.
Target design
An architecture with alternatives and the cost of each — with a recommendation, not a single option.
Validated plan
Migration and rollback tested in the lab, then broken into work windows.
Implementation
In stages, each with its own acceptance criteria.
Documentation and runbooks
Diagrams, addressing plan and procedures in a format your team will keep updated.
Handover and training
Your engineers run the changes themselves; we stay on a retainer if you want one.
Architecture
Architecture
- 01AuditTopology, SPOFs and technical debt
- 02DesignAlternatives, and the cost of each
- 03ValidateMigration and rollback, in the lab
- EVE-NG
- Rollback test
- 04ImplementIn stages, each with acceptance criteria
- 05DocumentDiagrams, the addressing plan, runbooks
- 06HandoverYour team runs the changes themselves
Operator consoles
Operator consoles
These exact systems run on the group's own infrastructure — the screenshots are processed before publication.
The virtualization cluster
A multi-node Proxmox cluster: KVM virtual machines and LXC containers, NFS/HA storage, a separate backup NAS and migrated ESXi hosts. This website runs on it too — in a container, on the same infrastructure we sell.
8 clusters from one interface
Proxmox Datacenter Manager brings independent Proxmox VE clusters into one place. In our own infrastructure it manages 8 of them, spread across separate physical locations — 3 of those outside Georgia. The frame also shows the scale: 211 nodes online, 1,480 virtual machines and 127 containers — one view, one procedure.
vSphere — the cluster, its hosts and the workloads on it
A vCenter with several ESXi hosts and the services placed on them: web, billing, a domain controller, backup agents. This is the environment where VMware and Proxmox coexist — part of it still on vSphere, part already migrated. One team operates both, under one backup policy.
Storage — ZFS pools and replication
ZFS storage on a RAIDZ2 topology — 12 disks in one vdev, roughly 33 TiB usable, ECC memory with most of it serving as ZFS cache. And the part that matters: disks with errors, zero; scrub and scan, clean. This is the layer underneath the virtualization cluster and the backups.
ISP billing and subscriber management
The whole subscriber lifecycle in one system: tariffs, balances, services (internet, Wi-Fi, IPTV), statuses, SMS notifications, logs and financial reports — wired into provisioning. We built it, and it runs a real ISP.
IPAM — the address space in one system
A live phpIPAM deployment: subnet hierarchy, VLAN domains, VRFs, devices and locations in one searchable database. Only the aggregate statistics are public — customer names, individual subnets and locations are not on the frame, and should not be.
The digital twin — the lab that comes before production
A topology built from real network operating systems: border routers, IXP and CDN peerings, the aggregation layer, VLANs and the management network — production, replicated in the lab. Migration, failure and rollback run here first; only then does anyone touch the live network.
Capabilities
Capabilities
Every item is marked: verified production experience, or engineering capability.
BGP and multi-homed edge
Proven- BGP
- OSPF
- RPKI
MPLS core and L3VPN
Capability- MPLS
- MP-BGP
- L3VPN
Virtualization clusters
Proven- KVM
- Proxmox VE
- VMware
EVPN-VXLAN fabric
Capability- Arista
- Cumulus
- FRR
Ceph / ZFS storage
Capability- Ceph
- ZFS
- NVMe
Automation and IaC
Capability- Ansible
- Terraform
- GitOps
Internal portals and APIs
ProvenA hosting control panel with hourly billing and provisioning automation — a working product, not a prototype.
- Next.js
- PostgreSQL
- REST
Purpose-built operational tooling
ProvenWhen an off-the-shelf product does not answer the question, we build our own: a NOC console with live path monitoring, and the 33 diagnostic tools on noc.com.ge — both in daily use on our own network.
- OpenPath
- noc.com.ge
- PHP / TypeScript
Process
Process
- 01
Audit
- 02
Design
- 03
Validate
- 04
Implement
- 05
Document
- 06
Handover
Technology stack
Technology stack
- Routing and switching
- CiscoJuniperMikroTikAristaFRR
- Virtualization
- VMware vSphereProxmox VEKVMLXC
- Storage
- TrueNASZFSNFSiSCSI
- Automation
- AnsibleTerraformcloud-initGit
- Development
- TypeScriptNext.jsPHPPostgreSQLREST API
- Validation and monitoring
- EVE-NGZabbixPrometheusGrafanaLibreNMS
Engagement model
Engagement model
Project
A one-off scope: audit, migration or implementation with a fixed outcome.
Retainer
Monthly engineering hours — specialist access on demand.
Use cases
Use cases
A migration against a deadline
A licence or hardware support contract is expiring. We produce the target design, prove it on a digital twin and move in stages — the deadline drives the schedule, not the architecture.
Two networks become one
After a merger the address space overlaps, VLAN numbering differs and each side has its own procedures. We produce one plan and join them without stopping the service.
The in-house team cannot keep up with growth
The engineers are consumed by day-to-day operations and never start the project. We take the project work while the team keeps production running, then hand it back with the documentation.
FAQ
FAQ
Will you tie us to one vendor?
No. We operate Cisco, Juniper, MikroTik, Arista, VMware and Proxmox in production — the recommendation comes after the audit and follows your existing hardware, budget and team experience.
Do you only design, or implement as well?
Both. An audit and a design can be bought on their own, but the standard project ends with implementation, documentation and handover — and afterwards, if you want it, with us operating the result.
Do you stay after the project?
Whichever you prefer: handover only, monthly engineering hours, a co-managed model, or fully managed operation. In every case the documentation is yours.