Taking on new work

Systems that stay up when nobody's watching.

I design, build and run self-hosted infrastructure, automation pipelines and AI tooling for teams who would rather not think about their servers. Docker-first, monitored, and still readable six months after launch.

Based in the Netherlands Working across Europe Reach me on Telegram
Operating snapshot
Uptime approach
Monitored firstalerts before users
Delivery
Docker-firstreproducible
Storage
S3 / MinIOsigned access
Access
Segmentedleast privilege
$ okiu status --all
Everything here runs on infrastructure I maintain myself.
01 Focus infra · automation · ai

Three things I'm actually good at.

Infrastructure and automation are the base. AI goes in when it removes real work, not because it looks good on a slide.

Infrastructure & hosting

Self-hosted platforms built to survive updates, restarts and the person who inherits them.

  • Docker-first stacks with reproducible deploys
  • Network segmentation and controlled remote access
  • Backups that get restored, not just scheduled

Automation & tooling

Repetitive work turned into something that runs on its own and tells you when it doesn't.

  • Deploy and maintenance pipelines
  • Monitoring and alerting wired in from day one
  • Internal tools that fit how the team already works

AI & integrations

Local models and retrieval pipelines wired into products, kept private and predictable.

  • Self-hosted model environments and tuning
  • RAG and knowledge retrieval over your own data
  • AI features that ship inside real products
02 Work 6 systems · filter by state

Built, running, and still being changed.

A selection of systems I've built and operate. Automation-heavy, infrastructure-backed, and designed to grow without a rewrite.

Telegram download automation

Live

A Pyrogram bot that watches authorised groups, calls custom API endpoints, fetches the content and caches the result — so the same file is never pulled twice. Permissions, rate limits and cleanup rules are built in so it behaves in busy groups.

pythonpyrogramsqlitecaching

S3 / MinIO delivery layer

Live

Upload and delivery flow on S3-compatible storage with short-lived signed links. Repeat requests mint a fresh temporary URL against the stored object instead of downloading anything again.

s3miniosigned-urlsstorage

Large file handling for Telegram

Live

Operational tooling for oversized assets: zip packaging, splitting when a file exceeds the limit, part tracking in a database, and cached re-delivery so a group never re-uploads the same archive.

telegramfilescachingops

Backup & sync automation

Maintained

An rclone-based backup routine tuned for large datasets, built around predictable runs, visible progress and as little daily friction as possible. Boring on purpose.

rclonebackupwindowsautomation

Disposable VM analysis sandbox

Building

A self-hosted malware analysis platform that spins up throwaway VMs on demand, caps each session by time, and destroys everything afterwards. Currently in design and prototyping.

virtualisationsecurityautomation

Track & trace platform

Building

Delivery tracking with an admin panel, package management and GPS updates from drivers to estimate arrival windows. Web-first, with a backend structured for a real fleet rather than a demo.

webbackendtrackingmongodb
03 Stack tools · and the rules behind them

Chosen for uptime, not for the résumé.

Nothing here is exotic. Everything here is something I've operated long enough to know how it fails.

Infrastructure

DockerLinuxWindows ServerVLANsReverse proxies

Languages

PythonPHPJavaScriptBashPyrogram

Storage & delivery

S3 / MinIOSigned URLsSQLiteMongoDBRclone

AI & data

Local LLM runtimesRAG pipelinesEmbeddingsLLM tooling

Operating rules

Five things I don't negotiate on.

  • 01Clarity beats cleverness
  • 02Stability comes first
  • 03Performance is a feature
  • 04Automate anything done twice
  • 05Leave it maintainable
04 Disclosure exposed data · notification only
Coordinated disclosure · no system access

When I find something that isn't mine to find.

Working across infrastructure and open data occasionally means running into things that shouldn't be reachable — an open storage bucket, a leaked credential set, an exposed admin panel. When that happens, I tell the owner. I don't do anything else.

How it worksWhat actually happens

  1. 01Discovery. Something turns up during normal work or research — never through scanning, probing or testing systems I don't have permission to touch.
  2. 02Verification. I confirm the exposure is real using only what's already publicly reachable. No login attempts, no credentials used, no further access.
  3. 03Identification. I work out who owns the system or account, so the report reaches someone who can actually act on it.
  4. 04Notification. I contact them directly — email, a disclosure form, or a phone call — and explain what's exposed and why it matters.

That's the full extent of it. Whether or how they act on it is entirely theirs to decide — I don't monitor, chase, or follow up.

Hard limitsWhat I never do

  • Log into an account or system that isn't mine, under any circumstances
  • Change, delete or move anything — no desktop backgrounds, no files, no settings
  • Copy, download or retain data beyond what's needed to confirm the exposure and identify the owner
  • Ask for payment, or treat the report as leverage of any kind
  • Publish specifics that could help anyone else find or exploit the same exposure
In short: the report is the entire interaction. Everything here follows ordinary coordinated-vulnerability-disclosure practice — the same norm behind bug-bounty programs and a site's security.txt — and stays fully outside the system the whole time.
05 Contact one channel · fast replies

Got a system that needs to stop breaking?

Tell me what you're running and where it hurts. If it's something I can help with, you'll get a straight answer — and if it isn't, I'll tell you that too.

No LinkedIn, no contact form. Telegram is the fastest route.
t.me/okiuc · github.com/OKiU-Network-Europe