Method and infrastructure
60 containers, zero open ports
Every system in this portfolio runs on my own server, is published through an encrypted tunnel, and is deployed following the same written procedure. This page explains how, because the way a supplier operates says more about them than the list of technologies they know.
~60
containers on my own server
0
ports open to the internet
11
monitoring agents with least privilege
3
mandatory checks after every deployment
Where everything lives
Production runs on my own server with around sixty Docker containers: databases, applications, WhatsApp agents, client sites and internal services. There is no third-party cloud charging per process, and there is not a single port open on the router.
All traffic comes in through an encrypted tunnel connecting the server to the public domains: mine and each client's. From the outside, the only thing that exists is the domain; the machine is not exposed and cannot be reached directly.
That topology is not an aesthetic preference. A server with no open ports removes at a stroke the entire category of attacks that begin by scanning addresses looking for forgotten services.
The same procedure in every project
Every project has its deployment document and they all follow the same format. It is not bureaucracy: it is what makes it possible to deploy at eleven at night without improvising.
-
build Step 1
Build
The release is built and the automated gates have to pass green.
-
backup Step 2
Back up
What is live gets backed up before touching it, not after breaking it.
-
sync Step 3
Sync
The new version is published to the real destination.
-
checklist Step 4
Three checks
Container healthy, answers locally, answers over the internet. All three, in that order.
-
undo Step 5
Rollback
If anything fails, roll back to the previous tagged version. No debate.
Why the procedure is always the same
Every project has its deployment document and they are all written in the same format. That means picking up a system I have not touched in two months requires remembering nothing: the document says what gets built, what gets backed up, where it is published and how it is checked.
Verification is three questions, always in the same order: is the container healthy? does it answer from the machine itself? does it answer from the internet? Skipping the order wastes time, because each question rules out a different cause.
And if something fails, no fix is improvised while the system is down: roll back to the previous tagged version and investigate calmly. Being able to go back is what allows moving fast.
Eleven agents with the least privilege possible
The agents that watch and operate the server are written in bash and split by permission level. Most of them only look. The ones that can act, act within written limits.
Watch without touching
Most agents observe and report; they have no permission to change anything.
A message is never an order
The Telegram coordinator accepts no free-form language: only a fixed list of known commands.
Prepares, does not execute
One agent leaves the work ready for a person; running it is not its job.
A traffic light before any change
Green, amber or red before a modification to the server is allowed.
What is not touched without approval
A master registry lists what nobody modifies without explicit authorisation.
How I build with AI agents
The projects in this portfolio are built with language models, and I say so openly because the interesting part is not that I use them, it is how. There is no assistant being told «build me a system»: there are separate roles and gates that have to be passed.
One model plans: it produces the diagnosis, argues the decisions, and writes the brief with its scope, its rules and its acceptance criteria. Another builds from that brief. And between finished work and deployment there are automated verification gates: tests, comparators confirming the content did not change where it should not have, and sensitive-data checkers that fail the build if they find something that cannot be published.
Nothing ships unless the gates pass green, and no business decision is made by a model: a person approves them. Artificial intelligence speeds up execution; it does not replace judgement or the responsibility for what gets published.
This very page is an example of the method: it was planned as a written brief, built from it, and did not reach publication until the sensitive-data checker and the metadata checker both passed green.
What this means for a client
- check_circle That their system does not depend on me remembering how it was deployed: it is written down.
- check_circle That a failed deployment is rolled back instead of turning into a night of improvisation.
- check_circle That the automation watching the server cannot do more than it is allowed to.
- check_circle And that what gets published passes automated checks first, not just good intentions.
If you have a system in production and you are not sure how it is deployed, how it is backed up, or what happens when it fails, that conversation is free.
mail Let's talk