<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 buy used homelab hardware when the workload needs ordinary compute, memory, and storage more than it needs a new-server warranty. My current example is a group of five Lenovo ThinkCentre M900 Tiny systems that I bought for $50 each, then equipped with compatible RAM and NVMe SSDs. I use separate machines for services such as Postiz, Nextcloud, and other personal workloads. Those are my purchase results, not a price promise. The useful lesson is the buying process: calculate the finished cost, verify the exact configuration, test every component, and decide how you will recover when an older machine fails.</p>

<h2>New hardware was solving the wrong problem</h2>

<p>Server launches are fun to follow, but my homelab does not need the newest platform for every service. A social scheduler, private cloud, monitoring tool, or small development environment may spend much of its time waiting for a request. I would rather match each workload to a machine than buy one expensive system because its benchmark chart looks impressive.</p>

<p>Business refresh cycles put many small desktops on the used market while they still have useful life. That does not make every retired PC a bargain. It creates inventory with uneven condition, missing adapters, unknown storage history, and many configurations sharing one model name. I treat the listing as a lead. The model number, seller photos, serial-specific parts information, and a testable return policy decide whether I buy it.</p>

<h2>My five-M900 approach</h2>

<p>I bought five ThinkCentre M900 Tiny systems for $50 apiece. Inexpensive compatible memory and NVMe SSDs let me prepare them for separate jobs. The small nodes give me isolation without forcing every service into one large host. I can reboot the Postiz machine without taking down Nextcloud, and I can experiment on another node without changing the machines that hold persistent workloads.</p>

<p>This layout also gives me a practical spare-parts strategy. Matching systems can share adapters and known-good test parts. If one node fails, I can move a backed-up workload to another machine while I diagnose it. Five older computers also mean five operating systems, five storage devices, and five sets of updates. The arrangement only helps when I keep a basic inventory and use repeatable configuration and backup procedures.</p>

<p>My <a href="/blog/self-host-postiz-thinkcentre-m900-tiny">Postiz self-hosting draft</a> shows the single-purpose version of this idea. The hardware boundary is easy to understand: that machine runs the scheduler and its supporting services. I still need monitoring and recovery evidence before I call the workload dependable.</p>

<h2>Verify the exact machine before buying parts</h2>

<p>The <a href="https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCentre_M900_Tiny/ThinkCentre_M900_Tiny_Spec.PDF" rel="noopener noreferrer">Lenovo M900 Tiny Product Specifications Reference</a> lists several processor options, two DDR4 SO-DIMM sockets, and configurations that shipped with either 2.5-inch SATA storage or an M.2 SSD using a PCIe or SATA interface. That range is the reason I avoid statements such as "an M900 has this CPU" or "any M.2 drive will work." The family specification describes possible configurations, not the parts inside a particular used unit.</p>

<p>I ask for the full machine type and clear photos, then check the installed processor, memory, storage tray, M.2 hardware, optional ports, wireless card, and power adapter. I verify the memory generation, module type, supported capacity, storage keying and length, and interface. I also check whether the seller removed a proprietary cable or caddy while taking out the original drive. A cheap bare system becomes expensive when several small missing pieces must ship separately.</p>

<p>The <a href="https://download.lenovo.com/pccbbs/thinkcentre_pdf/m700_m900_m900x_tiny_hmm.pdf" rel="noopener noreferrer">Lenovo hardware maintenance manual</a> helps identify replaceable parts and the correct disassembly order. I read it before opening the case. I disconnect power, use sensible electrostatic precautions, and avoid forcing clips that are easy to mistake for screws.</p>

<h2>Calculate the finished cost</h2>

<p>The listing price is one line in the budget. I add memory, SSD, correct power adapter, mounting hardware, shipping, sales tax, and any parts needed to replace damaged cooling or storage hardware. I also reserve money for a failed unit. A $50 computer that needs $120 in parts should be compared with complete alternatives around the same finished price.</p>

<p>I value my time as part of the decision even when I do not assign it an hourly rate. Cleaning, firmware updates, memory tests, installation, and troubleshooting take an evening. That work is part of the hobby for me. Someone who needs a production service online by Friday may get better value from a newer system with support.</p>

<p>Electricity belongs in the comparison, but I measure it at the wall instead of copying a processor thermal-design number. Idle draw, storage, peripherals, firmware settings, and workload change the result. Several tiny PCs may use more power than one newer host, and they occupy more network ports and outlets. One large machine may need more memory and a stronger recovery plan because more services fail with it. I compare the systems using the workloads I plan to run.</p>

<h2>Where I look and what I ask</h2>

<p>Used business machines appear on eBay, ShopGoodwill, thrift-store shelves, local liquidators, electronics recyclers, and community marketplaces that allow sales. Each source shifts the risk. A recycler may know the machine's origin but offer limited testing. A marketplace seller may provide detailed photos and returns. A thrift-store purchase may be cheap but impossible to verify before checkout.</p>

<p>I look for photos of the actual unit, not a stock image. The useful listing shows the label, ports, case condition, BIOS screen, included adapter, and any missing drive hardware. I ask whether the computer reaches firmware setup, recognizes memory, and includes the pictured parts. "Powers on" does not confirm that it boots, passes a memory test, or has a working network interface.</p>

<p>I do not ask a seller to guarantee homelab performance. I ask for facts they can observe. I also read the return window before ordering upgrade parts. Testing the base machine after the deadline defeats much of the protection that made the listing acceptable.</p>

<h2>My intake test for used nodes</h2>

<p>I photograph the condition when the box arrives, then inspect the case, ports, fan, heat sink, board, storage connectors, and adapter. Dust is normal. Corrosion, liquid residue, damaged sockets, scorched components, or a rattling fan changes the decision. I compare the installed parts with the listing before adding my own hardware.</p>

<p>After the physical inspection, I load firmware defaults, review the boot order and device inventory, and install current vendor firmware when the change is appropriate for the exact machine. I run a memory test before trusting new or used modules. The <a href="https://www.memtest86.com/technical.htm" rel="noopener noreferrer">MemTest86 technical documentation</a> explains why memory tests use multiple patterns and algorithms; one successful boot cannot exercise memory the same way.</p>

<p>I inspect SSD health data and run the device's supported self-tests. The <a href="https://www.smartmontools.org/static/doxygen/" rel="noopener noreferrer">smartmontools documentation</a> covers ATA, SCSI, and NVMe devices through <code>smartctl</code> and <code>smartd</code>. SMART data helps me spot warning flags and record a baseline, but I do not treat a clean report as a warranty against failure.</p>

<p>The remaining test covers CPU load, temperatures, fan behavior, every network port I plan to use, USB ports, repeated cold boots, and several restarts. I measure wall power at idle and under a representative workload. I keep the results with the node inventory so a later temperature or storage change has a baseline.</p>

<h2>Plan for older hardware to fail</h2>

<p>I assume a used node can fail without warning. Persistent data goes to a tested backup destination, and the service configuration is stored separately from the machine. I record enough setup detail to rebuild the workload on another node. Backups are incomplete until I have restored them into a clean environment.</p>

<p>Single-purpose nodes make replacement easier when the workload has a clear boundary. They can also hide dependencies if DNS, authentication, storage, and monitoring live elsewhere with no documentation. I map those dependencies before calling a service portable. My broader <a href="/blog/website-handoff-maintenance-plan-checklist">website handoff and maintenance checklist</a> uses the same ownership principle for production websites.</p>

<h2>Used hardware is a trade, not a shortcut</h2>

<p>I trade warranty length, expansion, and some energy efficiency for a low entry cost and several replaceable nodes. I also accept seller risk and more testing. The five M900 Tiny systems work for my homelab because I enjoy that operating work and can isolate services such as Postiz and Nextcloud. A new server remains the better choice when a workload needs vendor support, newer platform features, dense expansion, or a firm replacement timeline.</p>

<p>Before I buy another used tiny PC, I check the complete configuration, finished cost, return terms, workload fit, power estimate, and recovery plan. Then I test it before it holds anything important. That routine matters more than the logo on the case or the excitement around the newest server release.</p>

<h2>Planning a practical homelab?</h2>

<p>I can help separate workloads, document recovery boundaries, and turn a collection of small computers into an understandable service plan. See my <a href="/services/devops-consulting">DevOps consulting services</a> or share the nonsecret parts of your setup through the <a href="/contact">contact page</a>.</p>

See how I buy, upgrade, test, and deploy used homelab hardware, including five $50 ThinkCentre M900 Tiny systems used as separate service nodes.

Why I Buy Used Homelab Hardware for Servers

Five used ThinkCentre M900 Tiny systems gave me inexpensive, replaceable homelab nodes after I verified compatibility, tested every unit, and planned for failure.

Why I Buy Used Homelab Hardware Instead of Chasing New Server Hype

<p>Strapi Cloud and self-hosting run the same kind of content application, but they assign operational work to different people. Strapi Cloud manages more of the platform. A self-hosted deployment gives your team more control over the infrastructure and more responsibility for keeping it recoverable.</p>

<h2>Compare ownership before price</h2>
<p>A monthly hosting number is incomplete unless it includes staff time, backups, monitoring, updates, storage, data transfer, incident response, and recovery testing. Write down who owns each responsibility under both options before comparing plans.</p>

<h2>Strapi Cloud</h2>
<p>Strapi Cloud is the managed option from Strapi. It can reduce the amount of hosting configuration your team maintains and keeps the application within Strapi's supported cloud workflow. Check the current <a href="https://strapi.io/pricing-cloud" target="_blank" rel="noopener noreferrer">Strapi Cloud plans</a> for limits and included features because pricing and plan details can change.</p>
<p>It is a strong candidate when the team wants a supported deployment path, has standard infrastructure requirements, and would rather spend engineering time on content models and integrations.</p>

<h2>Self-hosting</h2>
<p>Self-hosting lets you choose the compute platform, database, region, storage, networking, monitoring, and deployment workflow. That flexibility can help when Strapi must fit an existing cloud environment or connect to private systems.</p>
<p>The team must own configuration, security updates, database and media backups, scaling, logs, alerts, releases, and recovery. Provider infrastructure does not replace an application-level operating plan.</p>

<h2>Decision table</h2>
<table>
  <thead><tr><th>Question</th><th>Strapi Cloud</th><th>Self-hosting</th></tr></thead>
  <tbody>
    <tr><td>Who manages the hosting platform?</td><td>Strapi manages more of the platform workflow.</td><td>Your team or provider manages it.</td></tr>
    <tr><td>Can you choose infrastructure details?</td><td>Within the available Strapi Cloud options.</td><td>Yes, subject to the selected provider.</td></tr>
    <tr><td>Who plans backups and recovery?</td><td>Review what the current plan includes and what remains yours.</td><td>Your team must design, monitor, and test recovery.</td></tr>
    <tr><td>Who handles upgrades?</td><td>Follow the managed platform's supported process.</td><td>Your team schedules, tests, and deploys them.</td></tr>
    <tr><td>How predictable is cost?</td><td>Plan pricing can be easier to estimate within its limits.</td><td>Cost depends on resources, transfer, storage, tools, and staff time.</td></tr>
  </tbody>
</table>

<h2>Questions that change the decision</h2>
<ul>
  <li>Does the application need a specific region, private network, database, or storage provider?</li>
  <li>Does the organization already have an AWS, Railway, Azure, or Google Cloud operating model?</li>
  <li>Who responds to an outage or failed deployment?</li>
  <li>How much content and media must be restored, and how fast?</li>
  <li>Does the team need custom plugins, build steps, or network access?</li>
  <li>Can the organization test upgrades before production?</li>
</ul>

<h2>Railway as a self-hosting option</h2>
<p>Railway documents a Strapi setup with PostgreSQL and persistent uploads through a volume or storage bucket. Its default application filesystem is ephemeral, so production media needs explicit persistence. The <a href="/blog/deploy-strapi-to-railway-no-template">manual Strapi on Railway guide</a> covers that configuration.</p>

<h2>AWS as a self-hosting option</h2>
<p>AWS gives teams many architecture choices, which can be useful when Strapi must integrate with existing identity, networking, storage, or monitoring. The tradeoff is design and operational complexity. A small content site should not inherit extra services unless its requirements justify them.</p>

<h2>Migration planning</h2>
<p>Moving between hosts requires more than deploying the repository. Inventory the database, uploaded media, environment variables, email provider, custom plugins, API tokens, domains, webhooks, frontend URLs, and scheduled work. Take a backup, test the restore in a non-production environment, lower DNS timing if appropriate, and define a rollback point.</p>

<h2>Which option fits?</h2>
<p>Choose Strapi Cloud when the managed workflow fits the application's limits and the team wants fewer infrastructure decisions. Choose self-hosting when infrastructure control, private connectivity, provider alignment, or custom operations justify the extra ownership. Review the decision again as traffic, staffing, and recovery requirements change.</p>
<p>If you need help with content modeling, migration, deployment, or maintenance, review <a href="/services/strapi-development">Strapi development services</a> or <a href="/contact">share the current setup</a> for a scoped recommendation.</p>

Compare Strapi Cloud and self-hosting by deployment ownership, infrastructure control, backups, upgrades, recovery, limits, and total operating cost.

Self-Hosting Resources & Benchmarks

Self-Hosting Postiz on a Dedicated ThinkCentre M900 Tiny

Why I Buy Used Homelab Hardware Instead of Chasing New Server Hype

Strapi Cloud vs. Self-Hosting: Ownership and Cost Guide

Need hands-on help with Self-Hosting?