Question

Nicola’s MyZubster Pilot Now Runs Locally with Docker—and We Verified the Data Survives

Today, Nicola’s independent MyZubster MVP completed another verifiable development cycle.

The objective was not merely to build a Docker image.

We wanted to prove the complete local workflow:

Clone → Build → Start → Create → Persist → Restart → Recreate → Verify

We completed every step on Nicola’s Windows computer.

What the project already had

The MVP exposes a small observation API.

Its first verified user story was:

Create an observation → HTTP 201 → JSON persistence → API retrieval → automated test

That implementation was reviewed and merged through a public pull request:

PR #1 — Verify observation creation, persistence and retrieval

The next question was:

Can someone run the same capability locally without manually configuring the Python environment?

Making the environment reproducible

We added:

• a Python slim Docker image;
• a non-root application user;
• Docker Compose configuration;
• a persistent volume;
• an API health check;
• configurable host, port and data-file location;
• Windows-oriented setup instructions;
• Docker verification in GitHub Actions.

The work was reviewed in:

PR #2 — Add reproducible Docker setup for local development

GitHub Actions successfully:

1. built the image;
2. started the container;
3. called the API;
4. created an observation;
5. retrieved the saved observation.

After the CI passed, the pull request was merged.

The first problem was not in the code

Nicola cloned the repository:

git clone https://github.com/nicolaususnicola-lgtm/myzubster-mvp.git
cd myzubster-mvp

The first Compose command failed:

failed to connect to the docker API at
npipe:////./pipe/dockerDesktopLinuxEngine

Docker’s command-line tools were installed, but the Docker Desktop Linux engine was not running.

We checked and updated WSL:

wsl --version
wsl --status
wsl --update
wsl --shutdown

After Docker Desktop was started, docker info confirmed:

• Linux containers;
• WSL 2;
• eight CPUs;
• approximately 15.5 GB of RAM;
• a functioning Docker server.

This distinction was important: reinstalling or changing the repository would not have fixed the problem.

Starting MyZubster

Nicola ran:

docker compose up --build -d
docker compose ps

The image was built and the API started successfully.

We then created an observation:

$body = @{
  description = "Prima osservazione Docker di Nicola"
  latitude = 44.0678
  longitude = 12.5695
} | ConvertTo-Json

Invoke-RestMethod `
  -Method Post `
  -Uri http://localhost:5000/api/observation `
  -ContentType "application/json" `
  -Body $body

The API returned an observation with ID:

b8e8d66b9bf5bd16

It included the description, coordinates and a UTC timestamp.

Verifying persistence

Reading the collection returned:

{
  "count": 1,
  "observations": [
    {
      "coordinates": {
        "lat": 44.0678,
        "lng": 12.5695
      },
      "description": "Prima osservazione Docker di Nicola",
      "id": "b8e8d66b9bf5bd16",
      "media_hash": "",
      "timestamp": "2026-09-02T08:51:57.067451+00:00"
    }
  ]
}

We then restarted the API service:

docker compose restart api

The same observation remained available.

But a container restart was not enough to prove the full persistence model.

Testing down → up

We removed the Compose environment:

docker compose down

The container stopped, while the named volume remained:

local     myzubster-mvp_observations-data

We deliberately avoided:

docker compose down -v

because -v would delete the data volume.

We then recreated the environment:

docker compose up -d

After the API returned, we queried it again.

The result still contained:

count: 1
id: b8e8d66b9bf5bd16

The observation survived both the container restart and the complete Compose recreation.

A problem we still found

During shutdown, the Flask development server did not terminate gracefully within Docker’s initial timeout.

The container eventually exited with code 137.

This did not delete the volume or corrupt the observation, but it exposed the next improvement:

• replace Flask’s development server with Gunicorn;
• verify graceful container shutdown;
• repeat the persistence test;
• add that behavior to CI.

The application is an MVP, not a production deployment, and the logs correctly say so.

What has actually been proven

We can now verify that:

• the public repository can be cloned on Windows;
• Docker builds the application;
• Compose starts the API;
• a health check confirms availability;
• the API returns HTTP 201 for a valid observation;
• the observation is persisted;
• it can be retrieved through the API;
• it survives a service restart;
• it survives docker compose down followed by up;
• no passwords or access tokens are required.

That is more valuable than saying “Docker support added.”

It is evidence that the workflow is reproducible.

Why this matters for MyZubster

MyZubster is exploring whether an ecosystem can scale through independently developed capabilities instead of only accumulating users.

Nicola’s MVP is still small.

But it now has:

• public source code;
• a verified API workflow;
• automated tests;
• Docker packaging;
• persistent local storage;
• successful CI;
• evidence reproduced on the project owner’s computer.

This is the development model we are testing:

Build → Validate → Connect → Measure → Verify → Replicate → Expand

One human + one AI

The collaboration follows a human-controlled model:

• Nicola owns and runs his project;
• the AI assists with analysis, implementation and troubleshooting;
• GitHub records the changes;
• CI verifies the automated workflow;
• local execution proves that the result works outside the development environment.

The AI does not decide that the software is finished.

The evidence tells us what works, while the remaining failures tell us what to improve next.

Next step

The next technical milestone is a graceful production-style container lifecycle:

1. add Gunicorn;
2. verify clean shutdown;
3. preserve the current persistent volume behavior;
4. repeat the local Windows test;
5. record the result publicly.

For now, Nicola can accurately say:

MyZubster runs locally with Docker and preserves its observation data.

Repository:
github.com/nicolaususnicola-lgtm/myzubster-mvp

Main ecosystem:
github.com/MyZubster-Ecosystem/myzubster

Website:
myzubster.com

What do you consider sufficient evidence that a Dockerized MVP is genuinely reproducible?