Independent IT consulting · Istanbul, Türkiye
I take on the infrastructure work there is never time for.
scoped by a human · executed by agents · logged end to end
Patch backlogs, migrations, hardening, the runbook nobody has time to write. I scope the work and stay accountable for it. Agents carry out the execution over the same interfaces your administrators already use — WinRM, SSH, and your vendors' APIs — and every step lands in a log you can read afterwards.
Send me a task →from my own automation runs · updated by hand, not by a counter
01
Four hypervisors, three countries
This is not one client's estate. It is the range I work across day to day: enterprise vSphere on an HCI cluster, my own Proxmox node, servers in two clouds on two CPU architectures, and the container layers running on top of all of it. Every figure below was measured on 26 August 2026 — queried from the platform itself, not remembered.
platforms
- hypervisors
- VMware vSphere 7 · Proxmox VE 8 · Hetzner Cloud · Oracle Cloud (ARM64)
- container layers
- Docker · Incus/LXD system containers · Coolify PaaS
- virtual desktops
- VMware Horizon · ~50 desktops · ~31 concurrent sessions
- network and identity
- pfSense — itself a VM · WireGuard mesh · HAProxy · Active Directory
- storage and backup
- HPE SimpliVity HCI · ZFS · LVM-thin · Veeam · Proxmox Backup Server · S3
scale measured, not rounded
- physical hosts
- 5 · 128 cores / 256 threads · ~1.37 TB RAM
- virtual machines
- 99 across four hypervisors · 71 on vSphere alone
- containers
- 19 system (LXC/Incus) · 88 application (Docker)
- production storage
- ~18 TB verified SAN · 3.4 TB on-prem pools · ~6 TB file services
- backup estate
- 49 TB NAS repository · 10 TB offsite object storage · 191 snapshots
- protected daily
- 25 VMs with a restore point in the last seven days
- private network
- 29 nodes · 3 countries · x86_64 and ARM64 · no open management ports
- verified access
- a proven method per host — an open port is not the same as a manageable one
beyond the hypervisor
- inventory of record
- 9,477 assets · 157 managed endpoints · 34 thin clients
- written memory
- 94 documents · 15,100 lines · 26 recorded failure patterns
- money-holding system
- 3,162 wallets · append-only ledger · 113,766-row reconciliation
- delivery cadence
- 2,335 commits · 216 migrations · 7 months unbroken
- field experience
- 22 years · systems and infrastructure in manufacturing
02
How an engagement runs
what you and I decidewhat the agents do
-
01
Scope
We agree what may change and what must not be touched. That boundary is the engagement — not a preference, a limit.
boundary compiled into pre-flight checks; the run refuses to start until they pass
-
02
Runbook
I write the procedure and walk you through it before anything touches a host. You see the commands, not a summary of them.
procedure executes against the hosts you named, over WinRM, SSH, or vendor APIs
-
03
Exceptions
Anything the runbook did not anticipate comes to me. Destructive steps wait for your approval, every time.
an out-of-scope condition halts the run and reports it — never improvises around it
-
04
Evidence
You finish with a record you can hand to an auditor, and a runbook your own team can run again without me.
every command, result and timestamp written to the run log as it happens
03
Three pieces of work, described in numbers
Client names are withheld. The figures are here to show the scale of the work, not the state of anyone's estate.
-
A · manufacturing plant · ongoing
Making a production estate handover-ready
A production estate grown over two decades: ~24 VMs, 9,477 inventoried assets, two vCenters, a 6 TB file server, 11 print queues. The brief was to make all of it operable by someone who had not lived through its history.
What that took: a canonical card per host and application, a verified access matrix that separates the port is open from we can actually manage it, and a library of 26 failures this environment has actually produced — each with the symptom that gives it away.
a new technician — or an agent — is productive on day one; a handover becomes a file, not an event
-
B · dealer networks · in production
A system that holds other people's money
3,162 employee wallets across four corporate dealer networks, millions of lira in balances and unissued vouchers. Boundary: no write access to the production database, ever; schema changes only through reviewed, git-first migrations.
Balances are never set by hand — a trigger writes them, and a correction is a reversing entry, not an edit. The accountant's reconciliation pack, 113,766 rows, is generated read-only from production.
every balance can be traced back to the entry that produced it — the reconciliation is evidence, not a summary
-
C · shop floor · shipped
A dashboard that stopped polling
A CNC machine-status board polled the MES database continuously to stay current. The database is production, and read-only was not negotiable.
Rebuilt as a single reader pushing over WebSocket, with the polling loop removed entirely.
~0.3% CPU and roughly 99% less bandwidth, at the same real time
04
What I take on
- Windows and Linux fleet operations. Patching, hardening, and the configuration drift that accumulates between audits.
- Virtualisation, migrations and version upgrades. vSphere, Proxmox and cloud KVM alike — with the rollback path written and tested before the first change lands.
- Runbook automation. The manual procedure your team repeats every month becomes one that executes itself and reports what it did.
- Line-of-business software when nothing off the shelf fits. E-invoicing straight against the integrator's SOAP interface, shop-floor dashboards, file-integrity monitoring on engineering data.
- Identity and access. Active Directory, LDAP-backed sign-in, password management, and agentless Windows administration over a private mesh instead of open ports.
- Audit evidence from real runs. Generated as the work happens, rather than written up afterwards from memory.
05
What I won't do
If you are letting agents near production, this list matters more than the one above.
- Run a destructive step without your approval. Every time — not just the first time.
- Let an agent improvise. An out-of-scope condition halts the run and reports it. It does not reason its way around the boundary.
- Ask for write access to your production database. Read-only diagnosis is the default; anything that changes state is named, approved, and logged.
- Bill you for work I did not put in writing first. Out of scope means quoted, not invoiced afterwards.
- Promise you "full compliance." I will tell you which half of it is mine and which half belongs to your vendors.
- Put hardware or licence costs through my invoice. You buy those directly, at your price.
- Sell you hours. You buy a defined outcome and an agreed response time; how and when the work happens is mine to manage.
06
How we would work together
- engagement
- A monthly retainer against a written scope. What is inside is guaranteed; what is outside is quoted separately before it runs.
- boundaries
- Before anything runs we agree what may change and what must not be touched. That list is the engagement.
- exit
- Thirty days' notice, either direction. The documentation stays with you. No lock-in — that is the point of writing it all down.
- knowledge transfer
- Training your people is a separate, time-boxed, billed item. Never a quiet giveaway, and never held hostage.
- the paperwork
- Invoiced from a Turkish sole proprietorship, VAT added on top. Correspondence in English or Turkish.
07
Start small
a defined first step
A two-week infrastructure review. You end up with a written account of what you are actually running, where it is exposed, and what to fix first — in the order I would fix it.
Read-only throughout. Nothing changes on your systems during the review, and no commitment is implied beyond those two weeks.
Or pick one task from the queue and send it to me. Scope, price and the limits we agree on come back in writing before anything runs.
andac@andackartal.comCorrespondence in English or Turkish.