DEV Community: DockSky

How I Gave My AI Persistent Memory: From Markdown Hacks to MCP

DockSky — Fri, 26 Jun 2026 05:59:27 +0000

June 2026 - In 2025 I hacked together a markdown-file solution to avoid re-explaining my context every session. It worked. Up to a point. Here is why I ended up building something different.

The problem, still very real

You know the scenario.

Session 1:

You: "I'm working on a FastAPI API with MySQL, deployed on a VPS..."
The AI: understands everything, codes perfectly.

Session 2, the next day:

You: "Continue yesterday's work."
The AI: "I don't have context on your project. Could you describe..."
You: 😤

This is not a bug. It is the nature of LLMs: zero memory between sessions. Every conversation starts from scratch.

With a complex project (API, frontend, Docker, VPS, multiple repos), re-explaining the context takes 10 to 15 minutes per session. Over a week: an hour lost. Over a month: a full day of work gone.

And the worst part: it is not the code that evaporates. It is the why. The decisions, the traps you avoided, the paths you dropped. Exactly what separates "it compiles" from "it is maintainable."

My first answer: the `/AI/memory/` folder (2025)

A DIY solution. One folder per project:

my-project/
├── AI/
│   └── memory/
│       ├── project_context.md
│       ├── tech_stack.md
│       └── code_registry.json

At session start:

"Read the files in /AI/memory/ to load the context."

Thirty seconds. The AI knows the project, the conventions, the architectural decisions. It worked.

For months I ran like this. Multiple repos. Multiple folders. Markdown everywhere. Then the cracks showed up.

The limits: why DIY is not enough

Manual maintenance

Every new endpoint, every architecture decision: you have to remember to update the files. When you juggle between sessions, especially with a brain that jumps from topic to topic, "do not forget to update" is precisely the starting problem.

Drift

A few weeks later, the markdown describes an architecture that no longer exists. The AI works from stale information. You do not always notice until the prod bug or the incoherent PR.

Copy-paste persists

You ask the AI to read local files. Or you copy the JSON yourself. It is not fluid. It is not reliable. And it does not scale when you go from one repo to four.

Fragmentation

docksky-api, docksky-web, tda-assistant-ui, infra... Each repo its own /AI/memory/ folder. No overview. Impossible to switch context without reloading manually.

Verdict: the method treated the symptom, not the cause. Context lived in dead files, updated when I thought of it. That is, not often enough.

MCP: what changes the game

In 2025, Anthropic published the Model Context Protocol (MCP): an open standard for an AI agent to interact with external data sources in a structured way.

Before:

"The AI reads files I prepared."

After:

"The AI calls tools and interacts directly with my knowledge base."

It reads context. It writes a note. It creates a journal entry. Without my intervention. No copy-paste. No asking whether I remembered to update the markdown.

The difference is not just technical. It is structural. Context is no longer a static file. It is a living system.

What I built: DockSky

I answered the problem by building DockSky. Not another chatbot, but a shared external brain between me and my AI.

A desktop app plus MCP server. When Cursor or Claude connects via MCP, the agent gets native tools to:

list my projects
load a specific project's context
read my facets (decisions, traps, patterns, technical info)
create a journal entry
update an action or a step

Two complementary layers:

	Facets	Journal
What	What is worth keeping	What I did, day by day
When	Thematic, long term	Chronological
Example	`TRAP: missing UpdateSourceTrigger on this binding`	"Fixed login bug, tested on staging"

The base is persistent. It is the same one I use daily in the app. When the AI notes a decision, it writes where I will find it tomorrow, not in a forgotten markdown file at the bottom of a repo.

Concrete results (dogfooding, several months)

Starting a session on an active project: under 30 seconds
The AI no longer asks "remind me of the architecture"
Decisions from one session are available in the next
Zero markdown files to maintain by hand
Git commits feed the journal automatically (post-commit hook)

It is not magic. It is discipline reinforced by the tool: one point done, one trace in DockSky, move to the next. Tech does not replace the habit. It makes it cheaper.

What I learned

AI memory is not in the model — it must be structured and reloadable.
Local markdown = good prototype, bad product — human maintenance is a guaranteed failure point.
MCP = the right level of abstraction — standardized tools, not artisanal copy-paste.
Intent over code — what matters is capturing the why as you go, not archiving 400 KB of transcript.

A recent dev.to post put it better than I could: "Agents write code, but they don't remember." Exactly. Generation is solved. Context persistence is not.

The minimal workflow (no DockSky required)

1 specific point → done → 2 lines of trace → next

A journal. A decisions file. Even a DECISIONS.md README. What matters: do not let intent evaporate.

DockSky is that workflow turned into a system.

Does this problem sound familiar?

DockSky is a project I am building because I needed it: a brain that jumps, multiple repos, AI sessions that restart from zero every time.

I am not looking for customers. I am looking for people who recognize this story and want to co-build, not just use a tool.

What I am offering

The crew (Équipage): a private space (Discord plus Pro access while we build) where we talk about product direction. Sort ideas. Make design calls. Say what works or blocks in real usage. Not a support channel. A kitchen where founders think before anything goes public.

You do not need to be an expert at everything. What I care about:

you live the same context / AI memory problem;
you want to contribute: field feedback, code, docs, UX ideas;
you accept we are building, not shipping a finished product.

What this is not

Not a "download for free" pitch
Not an obligation to test X hours per week
Not open enrollment. The crew opens by invitation, after I read your application

How to reach me

If this article resonated, get in touch. Comment here, or apply at docksky.fr/equipage.

Tell me what hooked you and what you would want to bring to the table. No marketing funnel. I read every message myself.

No commitment. Just see if we speak the same language.

How do you handle AI context between sessions today: markdown, rules files, something else? I would genuinely like to hear in the comments.

How I Set Up HAProxy + ProxySQL on a Single OVH VPS for My Solo SaaS

DockSky — Tue, 23 Jun 2026 05:31:05 +0000

TL;DR: I needed to expose MySQL on the internet without getting scanned into oblivion within 48 hours. I stacked HAProxy in front of ProxySQL in front of MySQL. It works. I also spent six hours fighting a proxy that reads its config file once in its life, then pretends it never met you.

The problem (or: why I didn't just buy an $80/month RDS)

I'm building DockSky, an indie SaaS, solo, on an 8 GB OVH VPS for about €14/month. No ops team. No "managed database" budget. Just me, Docker, and optimism.

Except DockSky isn't just a REST API with Postgres behind it. The product is managed multi-tenant MySQL: each customer gets their own MySQL user, their own credentials, real isolation. Not a tenant_id column and a prayer.

For that to work, I need external MySQL access on port 6033, without leaving MySQL wide open on the internet like a vending machine at 3 a.m.

Before ProxySQL, I already had HAProxy forwarding traffic to MySQL. It worked. In the sense that nobody had tried SELECT * FROM users WHERE 1=1 on me yet.

What I was missing:

Rate limiting at the network layer (a bot opening 500 connections is trivial)
Connection pooling (my VPS has 8 GB of RAM, not a datacenter)
A layer to route multi-tenant users without hand-editing MySQL every time someone signs up

So: a network gateway and a SQL gateway. Two tools, two jobs. Like a bouncer at the club door and another at the VIP bar. Except nobody's paying cover yet. Still in beta.

The architecture (Post-it edition)

Internet (port 6033, the only MySQL port open in UFW)
    ↓
HAProxy          → "Be nice, but not too many connections"
    ↓
ProxySQL         → "Does your user exist? Is this query acceptable?"
    ↓
MySQL 8.x        → localhost only, like a well-behaved introvert

On the side, Traefik handles HTTPS for admin interfaces:

haproxy-stats.docksky.fr to see if everything's green
proxysql-admin.docksky.fr to stare at tables I only half understand

I created the subdomains via the OVH DNS API. Because clicking 40 times in the OVH panel is the kind of task that makes me want to quit software and open a food truck.

What I actually deployed

1. Lock down MySQL (finally)

MySQL only listens locally:

ports:
  - "127.0.0.1:3306:3306"

Want my data? Get in line. Like the post office, but with rate limiting.

2. HAProxy: friendly but firm bouncer

Frontend on *:6033, backend to proxysql:6032:

stick-table type ip size 100k expire 30s store conn_cur,conn_rate(3s)
tcp-request connection track-sc0 src
tcp-request connection track-sc1 src
tcp-request connection reject if { sc0_conn_cur ge 5 }
tcp-request connection reject if { sc1_conn_rate ge 10 }

Human translation: 5 simultaneous connections max per IP, 10 new connections max every 3 seconds. Enough for an honest client. Not enough for a script kiddie with a for loop and too much free time.

3. ProxySQL: the six-hour side quest

Docker service with:

a template proxysql.cnf.template (no secrets in git, I learned that lesson earlier)
a custom entrypoint that generates config at startup
tmpfs on /var/lib/proxysql (more on that, it's the plot twist)
beta user sync from MySQL into ProxySQL at boot (otherwise every new DockSky customer means a manual intervention, and I don't have a support team)

The entrypoint waits for ProxySQL to be ready, then syncs users. Because ProxySQL takes 25 to 30 seconds to wake up. Like me, but without coffee.

4. Version everything before the VPS explodes

I spun up a docksky-infra repo with a full disaster recovery procedure. Because one day the VPS will die (Murphy's Law, Docker edition) and I don't want to rebuild this from memory on a Sunday night.

What broke (the part Dev.to loves)

Issue #1: Docker Compose 1.29.2

Symptom: KeyError: 'ContainerConfig'. Couldn't recreate containers.

My reaction: "It's not me, it's Docker." (Spoiler: it was Docker.)

Fix: upgrade to Docker Compose v2. docker compose, no hyphen. Like switching from a bike to a car, except the car costs fewer nerves.

Issue #2: ProxySQL and the ghost config file

The trap that ate six hours.

First boot: everything works. I think I'm a genius.

Container restart: Access denied. I think I'm an idiot.

Official docs, one killer sentence:

"After first startup the DB file is used instead of the config file"

ProxySQL creates an internal SQLite database on first boot. Then it ignores your .cnf like an ex ignoring your texts.

I tried:

--initial → nope
deleting the volume → the DB comes back, poltergeist style
native env vars → ProxySQL doesn't care

What actually works:

tmpfs on /var/lib/proxysql. SQLite dies on every restart, ProxySQL is forced to reread the template
custom entrypoint generates /etc/proxysql.cnf with real passwords (sed first, then perl when sed started giving me side-eye)
wait 30 seconds before testing. Otherwise you think it's broken when it's just slow

Trade-off: any live change in ProxySQL (INSERT INTO mysql_users, etc.) vanishes on restart. Source of truth is the template. Not the moody SQLite database.

Issue #3: HAProxy declares ProxySQL dead

Logs: Access denied for user 'monitor'

I'd set option mysql-check user monitor. Except in ProxySQL, monitor is for watching MySQL backends, not for saying "hey, you alive?" to the proxy itself.

Fix:

option tcp-check

Port open? It's UP. Stoic philosophy for healthchecks.

Issue #4: Two stick-tables, one angry HAProxy

Symptom: crash loop, stick-table name 'mysql-in' conflicts

I'd declared two separate tables. HAProxy doesn't share well. One table, two counters. Like a Paris studio, but for IPs.

Issue #5: `envsubst` doesn't exist in Alpine

Logs: envsubst: command not found

The ProxySQL image is minimal. I'd copied a 2019 Stack Overflow tutorial. Classic.

Fix: sed, then perl. The current wrapper uses perl. At some point you stop fighting sed and accept defeat with dignity.

Issue #6: The silent restart (a few weeks later)

ProxySQL refused connections after a restart. No noise. No email. No "sorry boss."

I caught it in metrics within 5 minutes. Fixed in 30. That's exactly why I have healthchecks and a dashboard. Not to look good on a "our stack" slide.

What's running today

Component	Role	Status
MySQL 8.4	Data	✅ localhost only
ProxySQL 2.7	Pooling + multi-tenant users	✅
HAProxy 2.8	Network rate limiting	✅ healthy
Traefik	HTTPS admin + rest of DockSky	✅

UFW: only 6033 is open for MySQL. Everything else goes through Traefik or stays on localhost. My security policy is "paranoid, but not paranoid enough to shut everything down and work from a Raspberry Pi in a closet."

Is it worth it for a solo SaaS?

Honestly: it depends.

Yes if:

you want multi-tenant MySQL without paying €80/month for managed DB
you'll read the docs when things break (and they will)
you document everything, because future you remembers nothing

No if:

you want to sleep without thinking about ProxySQL
you have 50 customers and no monitoring
you hate proxies with a SQLite personality disorder

For DockSky today, it's the right trade-off. A €14 VPS, a stack I understand layer by layer, and an infra repo I can rebuild from scratch if OVH decides on a Tuesday that my server has lived its best life.

What I learned

Upgrade your tooling before adding a critical service. Docker Compose v2 saved me before ProxySQL even showed up.
Read the official docs. The SQLite sentence was there. I just took 4 hours to find it.
Simple healthchecks beat clever ones. TCP check is ugly but works.
Wait 30 seconds. ProxySQL isn't lazy. It's… deliberate.
Version everything. Shout-out to my dated docker-compose.yml backup from November 17, 2025.
Monitor. A proxy that dies quietly is a proxy you discover when a customer DMs you.

The punchline

Here's the part that still makes me laugh.

The original project this stack was built for? I abandoned it. Dead. RIP. Somewhere in a folder with a name I try not to open.

But HAProxy, ProxySQL, the OVH VPS, the disaster recovery repo, the "wait 30 seconds or you'll think it's broken" wisdom? All of that got recycled into DockSky. Same infrastructure, different dream. Like keeping the engine from a car you totaled and dropping it into something that actually runs.

So no, I wouldn't recommend building this stack just to abandon the product. But if you're a solo dev who's already paid the tuition in broken healthchecks and angry SQLite databases, you might as well reuse the homework.

Questions? I'm at docksky.fr. Contact form. No Telegram bot that replies "have you tried turning it off and on again."

Stack: OVH VPS 8 GB · Debian · Docker Compose v2 · Traefik · HAProxy 2.8 · ProxySQL 2.7 · MySQL 8.4 · lots of logs

DEV Community: DockSky

How I Gave My AI Persistent Memory: From Markdown Hacks to MCP

The problem, still very real

My first answer: the /AI/memory/ folder (2025)

The limits: why DIY is not enough

Manual maintenance

Drift

Copy-paste persists

Fragmentation

MCP: what changes the game

What I built: DockSky

Concrete results (dogfooding, several months)

What I learned

The minimal workflow (no DockSky required)

Does this problem sound familiar?

What I am offering

What this is not

How to reach me

How I Set Up HAProxy + ProxySQL on a Single OVH VPS for My Solo SaaS

The problem (or: why I didn't just buy an $80/month RDS)

The architecture (Post-it edition)

What I actually deployed

1. Lock down MySQL (finally)

2. HAProxy: friendly but firm bouncer

3. ProxySQL: the six-hour side quest

4. Version everything before the VPS explodes

What broke (the part Dev.to loves)

Issue #1: Docker Compose 1.29.2

Issue #2: ProxySQL and the ghost config file

Issue #3: HAProxy declares ProxySQL dead

Issue #4: Two stick-tables, one angry HAProxy

Issue #5: envsubst doesn't exist in Alpine

Issue #6: The silent restart (a few weeks later)

What's running today

Is it worth it for a solo SaaS?

What I learned

The punchline

My first answer: the `/AI/memory/` folder (2025)

Issue #5: `envsubst` doesn't exist in Alpine