I Gave My AI Agent a Social Media Dashboard. Obviously Docker Had Other Plans.

I started with what sounded like a simple idea:

I want my AI agent to become my Postiz operator.

Postiz is a self-hosted social media scheduling tool. My agent runs on my VPS. In my head, the workflow was clean: install Postiz, connect it to the agent, let it help draft, schedule, and manage posts.

In reality, the first milestone was more basic:

Can I even create a Postiz account?

The answer, for a while, was no.

Hostinger had a one-click Postiz deployment, so I tried that first. The containers came up. Postgres was healthy. Redis was healthy. The web page loaded. But registration failed.

That’s the dangerous part of modern infrastructure: everything can look alive while the app is quietly dead inside.

The logs eventually told the truth. Postiz was trying to connect to Temporal on localhost:7233, but there was no Temporal service in the Docker Compose file. The backend failed to start properly, which meant the signup page was basically a beautiful front door attached to an unfinished house.

The fix was to replace the outdated one-click Compose setup with a more complete stack:

• Postiz app
• Postgres
• Redis
• Temporal
• Temporal Postgres
• Temporal Elasticsearch

Once Temporal was added and TEMPORAL_ADDRESS=temporal:7233 was wired in, the backend finally started.

Then came the next failure: Gateway Timeout.

This one was a networking problem. Postiz was running in its own Docker network, while Traefik lived in Hostinger’s root_default network. Traefik could see the labels, but it couldn’t actually reach the container.

That was the second lesson:

Labels are not connectivity.

The fix was to attach the Postiz container to Traefik’s Docker network and add:

traefik.docker.network=root_default

After that, Postiz finally worked.

Then I moved it from Hostinger’s default domain to my own domain. That was worth doing early. For tools that will eventually involve OAuth, webhooks, APIs, and social accounts, the public URL matters. Changing it later can become annoying because third-party integrations often bind themselves to callback URLs.

The other major design decision was whether the agent should control Postiz through Docker or through Postiz itself.

At first, I wondered if I should install Postiz inside the agent’s own container so it could control things directly. That sounds convenient until you think about it for five minutes.

Postiz is not a tiny CLI tool. It is a real web app stack. It wants databases, queues, background workers, ports, persistent storage, and clean upgrades. Cramming that inside the AI agent’s container would make the system harder to reason about.

The cleaner architecture is to keep them as separate services. The agent should not become the Docker god of the server by default. The better pattern is to let Postiz run as a proper service, then give the agent app-level access through Postiz’s API, MCP server, or webhook system.

That distinction matters:

• Docker access means the agent can control infrastructure.
• API/MCP access means the agent can operate the application.

For a social media agent, I want the second one first.

The final learning was about secrets.

During the setup, a few sensitive values almost leaked through logs and terminal output. This is very easy to do when debugging Docker apps. Environment variables, process lists, status commands, and app logs can all expose tokens if you are careless.

So my rule going forward is simple:

Agents can verify that secrets exist, but they should not print them.

For example:

TELEGRAM_BOT_TOKEN=present
JWT_SECRET=present
DB_PASSWORD=present

Not the actual values.

Where I landed:

• The agent is alive on Telegram.
• Postiz is running and connected to my domain.
• Registration is disabled after creating my admin account.
• Postiz has the full supporting stack it needs.
• The next step is to connect the agent to Postiz through MCP/API access, not by giving it broad Docker control.

The meta-lesson?

“One-click deployment” is useful scaffolding, but it is not a substitute for understanding the moving parts.

In this one session, the actual work was not glamorous. It was mostly:

• reading logs
• checking environment variables
• understanding Docker networks
• fixing stale Compose templates
• deciding where the trust boundaries should be

But that is the real build story.

The magic is not that the AI agent can do everything.

The magic is slowly giving it the right handles, the right permissions, and the right boundaries, until it becomes useful without becoming dangerous.

That feels like the next phase of personal automation to me.

Not “AI replaces the operator.”

More like:

I am becoming the architect, and the agent is becoming the operator.

And yes, Docker still gets a vote.