<p>To self-host Postiz on a ThinkCentre M900 Tiny, I needed to plan for more than one application container. The documented stack uses PostgreSQL, Redis, Temporal, persistent storage, matching public URLs, and correctly registered social-provider callbacks. I chose a dedicated Lenovo ThinkCentre M900 Tiny so the service lifecycle stays separate from laptop shutdowns and unrelated homelab experiments. On August 23, 2026, the public hostname reached the Postiz authentication page through Cloudflare. That verifies public reachability, not container health, scheduled delivery, persistence, recovery, or uptime. I consider the setup dependable only when those host-side checks also pass.</p>

<h2>Why Postiz became its own machine</h2>

<p>I did not dedicate the M900 Tiny because Postiz needs exotic hardware. I did it because a scheduler is easier to reason about when its database, queues, uploads, and update cycle are not competing with unrelated experiments. A dedicated host keeps the service lifecycle separate from laptop shutdowns and unrelated lab-machine reboots. That architectural boundary does not by itself prove that scheduled posts have run reliably.</p><p>A tiny PC can be a practical middle ground for a personal workload, but the model name does not establish its installed CPU, memory, storage, power draw, purchase cost, or workload headroom. The documented fact here is that I chose a dedicated ThinkCentre M900 Tiny. It uses electricity and needs patches, storage checks, and backups. Self-hosting replaces a hosting bill with ownership; it does not remove operating work.</p>

<h2>Understand the four-service Postiz stack</h2>

<p>I start with the <a href="https://docs.postiz.com/self-host/installation/docker-compose" rel="noopener noreferrer">official Postiz Docker Compose guide</a> because the required services have changed across releases. The official stack connects Postiz with PostgreSQL, Redis, and Temporal. PostgreSQL stores application data, Redis supports fast shared state, and Temporal handles background workflow execution. Current Postiz releases require Temporal, which is one reason an older self-hosting tutorial can fail even when its commands look reasonable.</p><p>Most early failures came from how those services addressed one another. Inside Docker, PostgreSQL uses its Compose service name rather than <code>localhost</code>. The browser-facing frontend and backend URLs use public addresses, while container-to-container requests use the internal backend address. I check each hostname, protocol, and port separately because healthy containers do not prove that a browser can complete the request.</p>

<h2>How I expose it without exposing the host</h2>

<p>The M900 Tiny is the dedicated Postiz machine, while Cloudflare sits in front of the public Postiz hostname. On August 23, 2026, I checked <code>https://postiz.terryhunt.dev</code>: it redirected to the Postiz authentication route and returned a successful page behind Cloudflare. That check proves the public entry point reached Postiz on that date. It does not prove every container, integration, or scheduled job is healthy.</p><p>Tailscale is the intended private administration path, while public users and social-provider callbacks use the Cloudflare hostname. Local status confirms relevant Linux peers are online, but it does not identify the Postiz peer or prove that SSH and firewall rules enforce this separation. I verify the host identity and exposure policy separately, and I avoid putting private IPs, machine names, or access tokens in screenshots and tutorials.</p>

<h2>Match public, internal, and callback URLs exactly</h2>

<p>Most of my trouble came from settings that looked plausible but were wrong. <code>FRONTEND_URL</code> must match the address the browser actually uses, including the protocol and port. The backend URL must be reachable from the browser, while the internal URL must make sense between containers. The <a href="https://docs.postiz.com/self-host/troubleshooting" rel="noopener noreferrer">Postiz self-hosting troubleshooting guide</a> also warns that splitting the frontend and backend across incompatible parent domains can break OAuth state cookies.</p><p>The signing secret must be strong and persistent. Replacing <code>JWT_SECRET</code> during a restart logs users out and makes a normal redeploy look like an authentication problem. PostgreSQL data and uploaded media need persistent volumes. Social providers add their own developer apps, callback URLs, scopes, and approval rules. A correct Postiz deployment can still appear broken when one provider callback does not exactly match its registered value.</p>

<h2>Use prebuilt images and persistent volumes</h2>

<p>Postiz recommends its canonical Docker Compose repository and prebuilt image, and its documentation warns that a source build can run out of memory on a small server. The operating standard is to pin and review changes, pull the current Compose configuration, and read migration notes before replacing containers. I have not included host-side evidence of the M900's current image tag, Compose revision, or update procedure, so those remain items to verify before publication.</p><p>Container replacement should preserve the database, uploads, and secret values, but that requires verified mounts and stable secret configuration. The <a href="https://docs.postiz.com/self-host/installation/system-requirements" rel="noopener noreferrer">Postiz system requirements</a> gives a supported floor and a higher recommendation for a small team. The model name does not reveal this M900's installed memory or storage, and the public login response does not prove its persistence boundaries.</p>

<h2>My current ChatGPT and Codex handoff is manual</h2>

<p>In the workflow documented here, ChatGPT and Codex prepare copy without receiving my Postiz credentials. I use ChatGPT to explore an angle or rewrite a message for different networks. I use Codex when the post needs facts from the site repository, an article draft, or a repeatable structured format. I check the claims, links, tone, and private details before moving the result into Postiz.</p><p>For a simple post, I paste the approved copy into Postiz and save it as a draft. That manual step is useful because it forces one last look at the selected account, media crop, link preview, and schedule. Different social networks have different limits and conventions, so one long source paragraph should not be pushed everywhere unchanged.</p>

<h2>An optional API handoff I have not deployed</h2>

<p>Postiz also exposes a public API. A self-hosted instance uses its own backend URL with the <code>/public/v1</code> base path, and the API key comes from the developer settings described in the <a href="https://docs.postiz.com/public-api/introduction" rel="noopener noreferrer">Postiz Public API introduction</a>. The <a href="https://docs.postiz.com/public-api/posts/create" rel="noopener noreferrer">Postiz create-post endpoint</a> accepts a post type such as <code>draft</code>, <code>schedule</code>, or <code>now</code>, along with content and the connected integration identifier.</p><p>A small local script could accept reviewed JSON from Codex and create a Postiz draft. OpenAI's <a href="https://developers.openai.com/api/reference/resources/responses/methods/create" rel="noopener noreferrer">OpenAI Responses API reference</a> can generate text and request schema-constrained structured output. That makes the payload shape easier to validate; it does not validate the claims or make the Postiz handoff reliable by itself. I would keep the Postiz API key in the script environment, never in a chat prompt, and default every generated item to <code>draft</code>. Postiz would remain the calendar and final preview; a human would remain the publisher. This repository does not currently contain that connector.</p>

<h2>The checks I run after setup and updates</h2>

<p>A working login page is only the first check. My acceptance checklist confirms the application, PostgreSQL, Redis, and Temporal services are healthy. It creates a harmless draft, uses a test-capable social integration, previews its media and link, and schedules it far enough ahead to observe the workflow. It also restarts the host and verifies that secrets, database records, integrations, and uploads survive. This draft does not claim those host-side checks have passed; I need their dated results before publication.</p><p>Backups matter only if I know how to restore them. The database, uploads, Compose configuration, and secret inventory need a recovery plan that is stored away from the M900. Logs should be useful without containing post bodies, provider tokens, or session credentials. Those checks determine whether the scheduler can survive a restart and deliver a queued post.</p>

<h2>Decide whether the ownership is worth it</h2>

<p>Postiz can be a pain to self-host because it joins several moving parts with the strict callback rules of outside platforms. That frustration is concentrated at setup and upgrades. In return, I control the machine, the update timing, the content queue, and the path between my writing tools and the scheduler.</p><p>The dedicated ThinkCentre M900 Tiny makes that trade worthwhile for me because the boundary is obvious: this box runs Postiz. Someone who does not want to own Linux updates, backups, provider setup, and recovery may be happier with a managed service. For my homelab, that single-purpose boundary is the payoff I can support here; uptime and scheduling reliability still require host-side records.</p>

<h2>Planning a small self-hosted publishing stack?</h2>

<p>I can help map the containers, public URL, private access, backups, and review boundary before a social scheduler becomes another fragile box. Share the nonsecret parts of the plan through the <a href="/contact">contact page</a>, or see my <a href="/services/devops-consulting">DevOps consulting services</a>.</p>

See why I chose a ThinkCentre M900 Tiny for Postiz, how its documented hosting pieces fit, and which host-side checks still need verification.

Self-Hosting Postiz on a ThinkCentre M900 Tiny

Postiz took patience to self-host. A dedicated ThinkCentre M900 Tiny gives the service a clear boundary, with reliability verified through separate host-side checks.

Self-Hosting Postiz on a Dedicated ThinkCentre M900 Tiny

<p>I use ChatGPT to organize sanitized notes and Codex to compare a runbook with the repository commands it describes. The first draft is documentation, not an approved procedure. I test every command in a safe environment and record the expected output before another developer relies on it.</p><p>A useful runbook helps an operator decide whether to continue, stop, or escalate. A list of commands without targets and failure conditions can make an incident worse.</p>

<h2>Name the goal and owner</h2>

<p>The title describes the outcome, such as restoring a failed deployment or rotating an API credential. The first section names the service owner, approver, communication channel, and situations where the runbook applies.</p><p>I include explicit non-goals. An application restart procedure should not imply permission to change database schema or DNS.</p>

<h2>List prerequisites</h2>

<p>I record required access, tool versions, working directory, environment, backup state, and safe identifiers. Secret values remain in the owning secret manager. The operator verifies account and region with read-only commands.</p><p>Missing prerequisites stop the procedure. The runbook does not tell someone to work around access controls during an incident.</p>

<h2>Use copy-safe commands</h2>

<p>Commands use explicit targets and descriptive placeholders. I avoid unresolved destructive variables and broad recursive paths. Each command states whether it reads or changes state.</p><p>ChatGPT may improve wording, while Codex checks package scripts and file paths. I compare every suggestion with current code and official tool documentation.</p>

<h2>Show expected output and branches</h2>

<p>After each important command I include a short expected result and the next action for success or failure. Exact volatile output is less useful than a stable signal such as status, count range, or commit hash.</p><p>I define escalation points. Repeating a failed write command without understanding the error is not recovery.</p>

<h2>Document rollback</h2>

<p>The rollback section identifies the prior artifact, data restore point, configuration snapshot, and approval needed. Some changes cannot be reversed by redeploying code, so the runbook separates application, infrastructure, and data steps.</p><p>I test rollback in a non-production environment and record limitations rather than promising full recovery.</p>

<h2>Exercise and maintain the runbook</h2>

<p>Another developer follows the draft without oral help. I note unclear steps, missing access, unsafe assumptions, and elapsed time. The owner updates the runbook after platform or repository changes.</p><ul><li>Goal and scope are explicit.</li><li>Targets are verified read-only.</li><li>Commands avoid secret output.</li><li>Expected results guide decisions.</li><li>Rollback has test evidence.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev helps teams turn deployment knowledge into tested operating procedures through <a href="/services/devops-consulting">DevOps consulting</a>. Request a runbook review through the <a href="/contact">contact page</a> using sanitized examples.</p>

Write an AI-assisted DevOps runbook with a clear goal, owner, prerequisites, copy-safe commands, expected output, rollback steps, and test evidence.

Writing DevOps Runbooks with ChatGPT and Codex

Turn commands and incident notes into a tested DevOps runbook with owners, prerequisites, expected output, rollback, and safe targets.

<p>A failed CI log can contain hundreds of follow-on errors. I begin with the failing command and the first error that explains why the command stopped. ChatGPT can help summarize a pasted, sanitized excerpt. Codex can inspect the repository and run the matching command when it has authorized access.</p><p>I do not paste a complete log until I remove secrets, private package URLs, account identifiers, and customer data. The smallest useful excerpt often contains the command, runtime version, stack trace, and nearby setup lines.</p>

<h2>Capture the exact failure</h2>

<p>I record the workflow name, job, commit, command, exit code, and first useful error. Later errors may be symptoms of a missing generated file or failed install. I keep enough lines above the error to see environment setup.</p><p>I ask the assistant to distinguish facts in the log from hypotheses. A confident cause without a matching line or repository path stays unverified.</p>

<h2>Compare local and CI assumptions</h2>

<p>I compare Node and package-manager versions, lockfile use, environment variables, operating system, working directory, caches, and generated artifacts. The local command may pass because an ignored file exists or a developer shell exports a value.</p><p>I reproduce with the CI command in a clean environment where practical. Changing several dependencies before reproducing destroys evidence.</p>

<h2>Inspect the smallest relevant files</h2>

<p>Codex can trace the failing script into its configuration and imports. I limit the initial read to the workflow file, package script, failing module, and nearby test. This reduces speculation across unrelated code.</p><p>If the error concerns a missing secret, I verify the key name and job scope without revealing the value. If it concerns permissions, I inspect the required action before expanding a role.</p>

<h2>Make one testable change</h2>

<p>I choose the narrowest change that explains the failure: pin the supported runtime, generate the expected artifact, correct the path, or fix the type error. I add a regression test when the failure came from application behavior.</p><p>I avoid "cleanup" in the same patch. A small diff makes it clear whether the original cause was correct.</p>

<h2>Rerun the same command</h2>

<p>The original failing command must pass with the same relevant environment. I then run the surrounding project checks because a narrow fix can break another package or platform. CI receives the committed change and produces the final evidence.</p><p>I do not declare success from a local substitute if the failure happened only in the hosted runner.</p>

<h2>Write the incident note</h2>

<p>I record the first error, cause, fix, validation, and prevention. Repeated environment drift may justify a pinned toolchain or preflight script.</p><ul><li>Logs are sanitized.</li><li>The first causal error is identified.</li><li>Local and CI versions are compared.</li><li>One narrow fix is tested.</li><li>The hosted job passes on the target commit.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev helps teams diagnose builds and deployment pipelines through <a href="/services/devops-consulting">DevOps consulting</a>. Send the sanitized command and first error through the <a href="/contact">contact page</a>, not the full private log.</p>

Use AI-assisted CI debugging to isolate the first useful error, compare local and CI assumptions, inspect relevant files, and prove the fix safely.

Debugging a Failed CI Build with ChatGPT and Codex

Find the first useful CI error, compare environments, test the smallest cause, and prove the fix with the original command.

ChatGPT Resources & Benchmarks

Self-Hosting Postiz on a Dedicated ThinkCentre M900 Tiny

Writing DevOps Runbooks with ChatGPT and Codex

Debugging a Failed CI Build with ChatGPT and Codex

Need hands-on help with ChatGPT?