DEV Community: Aryan Iyappan

96.2% vs 6.9% — I Watched 5 Frontier LLMs Fail at Sudoku While an Energy-Based Model Solved It in 0.24s

Aryan Iyappan — Tue, 09 Jun 2026 14:00:01 +0000

I Watched 5 Frontier LLMs Fail at Sudoku While an Energy-Based Model Solved It in 0.24 Seconds

Yann LeCun chairs the technical board. The live demo makes his case better than any paper ever could — and the architecture implications go far deeper than puzzles.

Last week I spent an hour on a website that made me question everything I thought I knew about AI reasoning. It wasn't a research paper. It wasn't a benchmark leaderboard. It was a Sudoku solver.

I loaded a hard puzzle and clicked "Compare All Models." Six AI systems raced to solve it simultaneously.

Model	Result	Time	Cost
KONA 1.0 (EBM)	✅ Correct — valid grid	0.24s	Free
LLM 1	⏳ Timed out — never finished	20s+	—
LLM 2	⏳ Timed out — lost in reasoning	50s+	—
LLM 3	⏳ Timed out — reasoning diverged	50s+	—
LLM 4 (Gemini 3 Pro)	❌ API Error — returned 404	—	—
LLM 5	❌ Wrong — 14 duplicate digits	2.93s	$0.0005

The LLMs didn't just lose. They failed in ways that reveal structural limitations in how every frontier model today approaches reasoning.

LLMs 2 and 3 spent their entire runtime producing verbose chain-of-thought. "Let me analyze this row by row, column by column. Column 0 has 6, 9, 2, 5 filled, leaving 1, 3, 4, 7, 8. Box 3 in the middle-left has..." They generated hundreds of tokens of reasoning that looked correct at every step — identifying the right constraints, analyzing the right cells, considering the right candidates. And they never converged. The reasoning drifted. The constraints multiplied. There was no mechanism to notice that the chain of thought had become incoherent.

LLM 5 finished. It output a complete 9×9 grid with all cells filled and numbers in plausible positions. It had 14 duplicate digits across rows, columns, and boxes. The model produced output that was locally coherent — each token followed reasonably from the previous token — but globally broken.

The demo is at sudoku.logicalintelligence.com. Test it yourself before reading further — the experience of watching frontier models fail in real time while an unknown architecture succeeds changes how you think about AI reasoning.

The Architecture Problem Nobody Is Talking About

The company behind this is Logical Intelligence. Their product: Energy-Based Reasoning Models. Their flagship model: KONA. Their orchestrator: Aleph. And the name on their Technical Research Board is Yann LeCun — Founding Chair.

The team is serious. Michael Freedman — Fields Medalist, one of the most decorated mathematicians alive — is Chief Science Officer. Eve Bodnia is Founder and CEO. Boris Hanin (Princeton ORFE) is a technical advisor. This is not a side project.

LeCun has spent over a decade arguing that autoregressive LLMs cannot reach human-level reasoning. Most of the industry tuned him out because LLMs kept getting better at benchmarks. But this demo exposes exactly the limitations he's been warning about — and it's live, public, and testable by anyone with a browser.

To understand why the Sudoku demo is so revealing, you need to understand the structural difference between how LLMs and Energy-Based Models approach reasoning.

How LLMs Reason — And Why They Hit a Wall

Every frontier model today — GPT-5.2, Claude 4, Gemini 3, DeepSeek V3.2 — shares the same fundamental architecture: autoregressive generation. They produce tokens one at a time, left to right. Each token is a hard commitment. There's no native mechanism to go back and revise an earlier token when a later constraint invalidates it.

When an LLM "reasons," it produces a chain of thought — a sequence of tokens walking through the problem step by step. This works well for language because natural language is forgiving. Small inconsistencies don't break meaning. You can say something slightly contradictory and still be understood.

But reasoning has three structural problems when you try to do it autoregressively:

1. No undo. If step 7 contradicts step 2, you can't fix step 2. You'd need to regenerate every token from step 2 onward. In practice, the model doesn't even detect the contradiction — it keeps generating tokens that drift further from global consistency.

2. Locally scored. LLMs are trained to predict the next token given the previous ones. This optimizes for local coherence, not global correctness. A reasoning chain can be perfectly coherent at every step and still reach a fundamentally wrong conclusion. The training signal has no concept of "the final answer must satisfy all 27 constraints simultaneously."

3. Discrete token space. Reasoning traces are sequences of discrete tokens. You can't make small, gradient-based edits to improve consistency. Improvement requires discrete search, reranking, or resampling — all of which are expensive, lossy, and unreliable for long chains.

Here's exactly how an LLM approaches a constraint satisfaction problem:

The Sudoku demo demonstrates all three failures simultaneously. The LLMs produced reasoning that looked correct at each step. They identified the right constraints. They analyzed the right cells. They considered the right candidates. But they couldn't maintain global consistency across 81 cells and 27 constraints. The chain of thought drifted. Errors accumulated silently. There was no mechanism to notice, locate, or correct them.

This is not a "bad prompt" problem. It's not a "needs more training" problem. It's an architecture problem. The model was never designed to verify global consistency because its fundamental operation — predict the next token — has no concept of "the whole."

How Energy-Based Models Reason — And Why It's Different

EBMs work on a fundamentally different principle. Instead of generating tokens left to right, they learn an energy function — a scalar score that evaluates how consistent any state is with all constraints simultaneously.

Low energy = valid. High energy = something is broken.

The crucial property that makes this architecture categorically different: the energy function works on partial solutions. You can evaluate a half-completed grid and get actionable feedback on which specific constraints are being violated, and where the violation was introduced. This turns reasoning from a sampling problem (generate tokens, hope they're correct) into an optimization problem (minimize energy by satisfying constraints).

Logical Intelligence's three core theses — stated directly in their technical blog — are worth reading in full:

Thesis 1: LLMs are fundamentally limited as reasoning models due to their reliance on discrete tokens generated left-to-right. This is a serious impediment for scaling up AI reasoning.

Thesis 2: Energy-Based Reasoning Models overcome the main difficulties inherent in using LLM-based reasoning models. The key advantage: EBRMs provide a score you can apply to intermediate states that tells you whether you're staying consistent with global constraints and helps you pinpoint what is broken so you can repair it.

Thesis 3: Scaling AI reasoning requires using EBRMs for reasoning and LLMs for coordination, especially when translating to and from natural language instruction.

KONA, their flagship model, embodies all three theses. It is non-autoregressive at the trace level — it generates complete reasoning traces simultaneously and conditions directly on the problem constraints. It reasons in a continuous latent space using dense vector tokens rather than discrete ones, which enables gradient-based refinement. It is globally scored — the energy function evaluates end-to-end trace quality directly, so long-horizon coherence is trained and optimized natively.

The performance gap isn't subtle. On their benchmark of hard Sudoku puzzles:

Model	Accuracy	Avg Latency
KONA 1.0 (EBM)	96.2%	313 ms
GPT-5.2	6.9%	varies
Claude models	"close but still wrong"	"think for a long time"
DeepSeek V3.2	"fast but many duplicates"	"finishes quickly"

From their published benchmark results: "Claude models often think for a long time and then produce something close but still wrong. GPT-5.2 does best among the LLMs at 6.9%, which is still a 93% failure rate on a puzzle that any patient human can solve. DeepSeek V3.2 tends to finish quickly but with many duplicates across rows, columns, and boxes — failing to solve the puzzle."

The Bigger Picture: Aleph and PutnamBench

This isn't just about Sudoku. Logical Intelligence's orchestrator Aleph coordinates KONA, LLMs, and other tools in a compound system. Aleph recently achieved a near-perfect score on PutnamBench — a formal reasoning benchmark based on the William Lowell Putnam Mathematical Competition, widely considered the most prestigious university-level mathematics competition in North America.

These aren't grid puzzles. These are problems that most math PhDs cannot solve — problems where correctness is formally verifiable, meaning you cannot fake it with plausible-sounding output. The reasoning must be logically sound or it doesn't count at all.

Aleph has also topped other formal reasoning benchmarks, including MiniF2F and ProofNet. And in a separate result, Aleph formalized and disproved an open problem in planar unit distance graph theory — a problem in the Erdős unit distance problem family that had resisted resolution for years. The team published the formal Lean 4 proof alongside the result.

This is not an LLM getting lucky on a benchmark. This is an architecture designed from first principles to produce verifiably correct reasoning — and it's doing so at levels beyond what the best human mathematicians can achieve.

LeCun's Bet — And Why It Matters

LeCun's involvement isn't ceremonial. He has been the most prominent advocate for energy-based models in AI for over a decade. His position has been remarkably consistent across that entire period: autoregressive generation is a dead end for reasoning. The path to human-level AI requires architectures that can reason about constraints globally, not just generate sequences that are locally plausible.

He laid out this argument in detail in his 2022 position paper "A Path Towards Autonomous Machine Intelligence," where he proposed a cognitive architecture built around a "world model" — essentially an energy-based model that learns to predict and evaluate states of the world — coordinated with other modules for perception, memory, and action. The Logical Intelligence architecture (EBRMs for reasoning, LLMs for language, Aleph for orchestration) is the closest practical implementation of that vision that has been publicly demonstrated.

Most of the AI industry bet against this view. The reasoning was simple and, at the time, defensible: LLMs keep improving on benchmarks, so clearly the architecture is fine. Just scale it up. More parameters, more data, more GPUs. Hundreds of billions of dollars have been committed to this scaling hypothesis.

The Sudoku demo — and PutnamBench, and the formal verification results — suggest a different answer. Scaling doesn't fix the architecture. It produces longer, more articulate chains of wrong reasoning. The failure mode is not insufficient capability; it's a fundamental mismatch between the architecture and the task.

The vision isn't "EBMs replace LLMs." It's:

┌─────────────────────────────────────┐
│        HUMAN INTERACTION LAYER       │
│    (LLMs — language understanding,   │
│     generation, coordination)        │
├─────────────────────────────────────┤
│       ORCHESTRATION LAYER            │
│    (Aleph — planning, tool use,      │
│     result verification)             │
├─────────────────────────────────────┤
│        REASONING CORE                │
│    (EBRMs — constraint satisfaction, │
│     formal verification, planning)   │
└─────────────────────────────────────┘

LLMs generate candidates and handle human interaction — what they're architecturally suited for. EBRMs evaluate those candidates against formal constraints and guarantee correctness — what they're architecturally suited for. Orchestration coordinates between them, calling the right tool for the right sub-problem. Each component does what it was designed to do, rather than forcing one architecture to handle everything.

This mirrors how human cognition works, at least at a high level. We have intuitive, language-based thinking (Kahneman's System 1) and deliberate, constraint-aware reasoning (System 2). We don't try to solve math problems by generating plausible-sounding words and hoping the constraints work out. We use different cognitive systems for different kinds of thinking. The compound AI architecture does the same.

Why This Matters for Developers

If you're building AI systems today, you've almost certainly encountered the "looks right but is wrong" failure mode. An LLM generates code that compiles and passes a quick review — but has a subtle logic error that only manifests under specific conditions. Or it produces a deployment plan that sounds perfectly reasonable but violates a security constraint you forgot to state explicitly.

This is not a prompt engineering problem. The model has no mechanism for verifying global consistency because it wasn't designed to. Future iterations with more parameters will not fix this — they will produce the same class of error with higher confidence and more articulate justifications.

What makes Logical Intelligence worth paying attention to:

It's not a research paper — it's a live product. Load the demo at sudoku.logicalintelligence.com and test any frontier LLM against KONA yourself. The gap is not incremental. It is categorical.
The team is at the highest level. Yann LeCun (Turing Award, Chief AI Scientist at Meta), Michael Freedman (Fields Medalist), Eve Bodnia (Founder and CEO). The combined mathematical and engineering depth is extraordinary for a company this early.
The cost differential exposes the architectural inefficiency. The EBM solved the puzzle in 0.24 seconds running in-browser for free. The LLM that "succeeded" took 12x longer, cost real money, and produced the wrong answer. At scale — millions of reasoning queries per day — this difference compounds.
Constraint satisfaction is everywhere. Code verification, medical diagnosis, legal reasoning, chip design, structural engineering, financial compliance, robotics, scheduling — these are all fundamentally constraint satisfaction problems where being wrong is expensive. Any domain where constraints are non-negotiable and errors cascade is a domain where autoregressive generation is structurally insufficient.

The architecture conversation in AI is about to become harder to ignore. LLMs are remarkable at what they do — language. But reasoning, in the formal sense — maintaining global consistency while navigating constraint spaces — may require a fundamentally different approach. Logical Intelligence is building one. And the fact that Yann LeCun is betting his institutional credibility on it should make everyone pay closer attention than the industry currently is.

Try It Yourself

The demo is public and free:

Sudoku demo: sudoku.logicalintelligence.com
Company site: logicalintelligence.com
Technical blog posts:

Are energy-based models the next architecture shift, or a niche solution that LLMs will eventually absorb? I'm genuinely curious — especially from people building reasoning systems in production. Drop your take in the comments.

How I Self-Hosted Postiz with Tailscale (and the Env Vars the Docs Don't Tell You About)

Aryan Iyappan — Wed, 03 Jun 2026 08:22:47 +0000

How I Self-Hosted Postiz with Tailscale (and the Env Vars the Docs Don't Tell You About)

A step-by-step guide to running your own social media scheduler behind Tailscale — with the gotchas that cost me an afternoon.

I wanted a social media scheduler that I control. Not another SaaS subscription. Not another dashboard I log into that owns my data. Postiz is the best open-source option out there — 28+ platform integrations, a CLI, and a clean UI — but self-hosting it has a learning curve.

The docs will get you 80% of the way there. The other 20% — the env vars nobody mentions, the Tailscale networking trick, the Temporal stack — is what this post covers.

By the end, you'll have Postiz running on your server, accessible from anywhere via Tailscale's MagicDNS, with automatic HTTPS. No port forwarding. No Cloudflare Tunnels. No domain registrar.

What We're Building

┌──────────────────────────────────────────────┐
│                Your Server                     │
│                                                │
│  ┌──────────┐    ┌─────────────────────────┐  │
│  │ Tailscale │◄───│ network_mode: service    │  │
│  │ Container │    │ (Postiz rides Tailscale's │  │
│  │           │    │  network stack)           │  │
│  │ :443→5000 │    └─────────────────────────┘  │
│  └──────────┘              │                   │
│       │                    ▼                   │
│       │           ┌─────────────────┐          │
│       │           │   Postiz App    │          │
│       │           │   (port 5000)   │          │
│       │           └────────┬────────┘          │
│       │                    │                   │
│       ▼                    ▼                   │
│  MagicDNS HTTPS    ┌──────────────┐            │
│  postiz.tailXXXX   │  PostgreSQL  │            │
│  .ts.net           │  Redis       │            │
│                    │  Temporal    │            │
│                    └──────────────┘            │
└──────────────────────────────────────────────┘

The key insight: Postiz doesn't expose any ports to the host. Instead, it uses network_mode: service:tailscale to piggyback on Tailscale's network stack. Tailscale handles DNS, HTTPS certificates, and the encrypted tunnel. Postiz just thinks it's serving HTTP on localhost.

Prerequisites

A Linux server (Ubuntu 24.04 recommended) with at least 2GB RAM and 2 vCPUs
Docker and Docker Compose installed
A [Tailscale](undefined account (free tier is fine)
Basic comfort with editing YAML files

Step 1: Get Your Tailscale Auth Key

This is the key that lets your container join your Tailnet without manual authentication.

Go to [Tailscale Admin Console → Settings → Keys](undefined
Click Generate auth key
Set it to Reusable and Ephemeral: Off
Add a tag like tag:containers (you'll need this in your ACL later)
Copy the key — it starts with tskey-auth-

Note: The free tier gives you 3 users and 100 devices. One container = one device, so you've got plenty of room.

Step 2: Clone the Postiz Docker Compose Repo

git clone undefined
cd postiz-docker-compose

This gives you the base docker-compose.yaml plus the Temporal dynamic config files. Don't run it yet — we're going to modify it significantly.

Step 3: The Tailscale Service (This Is the Secret Sauce)

Add this service to your docker-compose.yaml. It sits above Postiz in the network stack:

services:
  tailscale:
    image: tailscale/tailscale:latest
    container_name: postiz-tailscale
    restart: unless-stopped
    hostname: postiz
    environment:
      - TS_AUTHKEY=tskey-auth-xxxxxxxxxxxxxxxxxxxx
      - TS_EXTRA_ARGS=--advertise-tags=tag:containers
      - TS_SERVE_CONFIG=/config/ts.json
      - TS_STATE_DIR=/var/lib/tailscale
    volumes:
      - ./tailscale-state:/var/lib/tailscale
      - ./tailscale-config:/config
      - /dev/net/tun:/dev/net/tun
    cap_add:
      - NET_ADMIN
      - NET_RAW
    healthcheck:
      test: ["CMD-SHELL", "tailscale status --peers=false --json | grep -q 'Online.*true'"]
      interval: 15s
      timeout: 5s
      retries: 10
      start_period: 30s
    networks:
      - postiz-network
      - temporal-network

What's happening here:

TS_AUTHKEY authenticates the container to your Tailnet
TS_EXTRA_ARGS advertises the tag:containers ACL tag
TS_SERVE_CONFIG points to a JSON file that tells Tailscale how to route traffic
/dev/net/tun is the kernel tunnel device — required for Tailscale to create its virtual network interface
NET_ADMIN and NET_RAW** capabilities let Tailscale manipulate the network stack
The healthcheck waits for Tailscale to report Online: true before Postiz starts

The Tailscale Serve Config

Create tailscale-config/ts.json:

{
  "TCP": {
    "443": {
      "HTTPS": true
    }
  },
  "Web": {
    "postiz.taila7d0df.ts.net:443": {
      "Handlers": {
        "/": {
          "Proxy": "undefined"
        }
      }
    }
  }
}

This tells Tailscale:

Listen on port 443 (HTTPS)
When a request comes in for postiz.tailXXXX.ts.net, proxy it to undefined (where Postiz listens)

Tailscale automatically provisions a Let's Encrypt certificate for *.ts.net domains. You get HTTPS with zero configuration.

⚠️ Replace postiz.taila7d0df.ts.net with your actual Tailscale MagicDNS name. You can find it in the Tailscale admin console under the machine's details, or run tailscale status once the container is up.

Step 4: The Postiz Service — Env Vars That Actually Matter

Here's the Postiz service, modified to work with Tailscale. This is where the docs fall short.

  postiz:
    image: ghcr.io/gitroomhq/postiz-app:v2.21.8
    container_name: postiz
    restart: always
    network_mode: service:tailscale   # ← THIS IS THE KEY LINE
    environment:
      # === URLs — MUST match your Tailscale MagicDNS name
      MAIN_URL: 'undefined'
      FRONTEND_URL: 'undefined'
      NEXT_PUBLIC_BACKEND_URL: 'undefined'

      # === Database & Redis
      JWT_SECRET: 'your-random-secret-string-here'
      DATABASE_URL: 'postgresql://postiz-user:postiz-password@postiz-postgres:5432/postiz-db-local'
      REDIS_URL: 'redis://postiz-redis:6379'

      # === Internal Communication (CRITICAL!)
      BACKEND_INTERNAL_URL: 'http://localhost:3000'
      TEMPORAL_ADDRESS: 'temporal:7233'

      # === Feature Flags
      IS_GENERAL: 'true'
      DISABLE_REGISTRATION: 'false'
      RUN_CRON: 'true'
      NOT_SECURED: 'false'

      # === Storage (Cloudflare R2)
      STORAGE_PROVIDER: 'cloudflare'
      CLOUDFLARE_ACCOUNT_ID: 'your-account-id'
      CLOUDFLARE_ACCESS_KEY: 'your-access-key'
      CLOUDFLARE_SECRET_ACCESS_KEY: 'your-secret-key'
      CLOUDFLARE_BUCKETNAME: 'your-bucket-name'
      CLOUDFLARE_BUCKET_URL: 'undefined'
      CLOUDFLARE_REGION: 'auto'

      # === Platform API Keys (fill in the platforms you use)
      X_API_KEY: ''
      X_API_SECRET: ''
      LINKEDIN_CLIENT_ID: ''
      LINKEDIN_CLIENT_SECRET: ''
      # ... (add keys for platforms you want to use)

      # === Misc
      OPENAI_API_KEY: ''
      API_LIMIT: 30

    volumes:
      - postiz-config:/config/
      - postiz-uploads:/uploads/
    depends_on:
      tailscale:
        condition: service_healthy
      postiz-postgres:
        condition: service_healthy
      postiz-redis:
        condition: service_healthy

The Env Vars That Cost Me an Afternoon

Here's what the official docs don't emphasize enough:

1. `BACKEND_INTERNAL_URL: 'http://localhost:3000'`

This is the most important env var you've never heard of. Postiz's server-side code makes API calls to itself. If this is wrong, OAuth callbacks fail silently, image uploads break, and you get mysterious 500 errors with no useful logs.

Always set this to http://localhost:3000 — not your public URL. The app listens on port 3000 internally. The network_mode: service:tailscale trick means Tailscale's port 5000 (or 443) proxies to this internal port. But the app itself needs to reach itself at localhost:3000.

2. `NEXT_PUBLIC_BACKEND_URL` MUST end with `/api`

This is the URL your browser uses to talk to the backend. If you forget the /api suffix, the frontend loads but every API call returns a 404. You'll stare at a blank dashboard wondering why nothing works.

✅ NEXT_PUBLIC_BACKEND_URL: 'undefined'
❌ NEXT_PUBLIC_BACKEND_URL: 'undefined'

The /api suffix is how the Next.js frontend routes API requests. Without it, the frontend sends requests to /graphql instead of /api/graphql, and nothing resolves.

3. `MAIN_URL` and `FRONTEND_URL` must be identical

In most web apps, these can be different. In Postiz, they interact with OAuth redirects, cookie domains, and CORS in ways that are not fully documented. Set them both to your full HTTPS URL and save yourself the debugging.

4. `RUN_CRON: 'true'`

Without this, your scheduled posts will never publish. Postiz uses an internal cron system (backed by Temporal) to fire posts at their scheduled time. If this is false or missing, posts sit in the queue forever.

5. `NOT_SECURED: 'false'`

When running behind a reverse proxy (Tailscale, in our case), this tells Postiz "trust the upstream HTTPS, don't enforce your own." If you set it to true, you'll get redirect loops and mixed content warnings.

Step 5: The Supporting Cast (PostgreSQL, Redis, Temporal)

Postiz needs Temporal for scheduling. The minimum stack looks like this:

  postiz-postgres:
    image: postgres:17-alpine
    container_name: postiz-postgres
    restart: always
    environment:
      POSTGRES_PASSWORD: postiz-password
      POSTGRES_USER: postiz-user
      POSTGRES_DB: postiz-db-local
    volumes:
      - postgres-volume:/var/lib/postgresql/data
    networks:
      - postiz-network
    healthcheck:
      test: pg_isready -U postiz-user -d postiz-db-local
      interval: 10s
      timeout: 3s
      retries: 3

  postiz-redis:
    image: redis:7.2
    container_name: postiz-redis
    restart: always
    healthcheck:
      test: redis-cli ping
      interval: 10s
      timeout: 3s
      retries: 3
    volumes:
      - postiz-redis-data:/data
    networks:
      - postiz-network

  # Temporal stack (required for scheduled publishing)
  temporal-postgresql:
    container_name: temporal-postgresql
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: temporal
      POSTGRES_USER: temporal
    networks:
      - temporal-network
    volumes:
      - /var/lib/postgresql/data

  temporal:
    container_name: temporal
    ports:
      - '7233:7233'
    image: temporalio/auto-setup:1.28.1
    depends_on:
      - temporal-postgresql
    environment:
      - DB=postgres12
      - DB_PORT=5432
      - POSTGRES_USER=temporal
      - POSTGRES_PWD=temporal
      - POSTGRES_SEEDS=temporal-postgresql
      - DYNAMIC_CONFIG_FILE_PATH=config/dynamicconfig/development-sql.yaml
    networks:
      - temporal-network
    volumes:
      - ./dynamicconfig:/etc/temporal/config/dynamicconfig

Why Temporal? Postiz uses Temporal for its background job engine. When you schedule a post for "tomorrow at 2 PM," a Temporal workflow sleeps until the right time, then fires the publishing pipeline. Without Temporal running, cron jobs work but scheduled publishing silently fails.

💡 Resource tip: Temporal + its PostgreSQL can consume 500MB-1GB RAM. If you're on a tight VPS, consider running Temporal on a separate machine or scaling down to 1GB RAM (set ES_JAVA_OPTS=-Xms100m -Xmx100m if using Elasticsearch).

Step 6: Networks and Volumes

volumes:
  postgres-volume:
    external: false
  postiz-redis-data:
    external: false
  postiz-config:
    external: false
  postiz-uploads:
    external: false

networks:
  postiz-network:
    external: false
  temporal-network:
    driver: bridge
    name: temporal-network

Two separate networks keep Postiz app data and Temporal data isolated. The Tailscale container bridges both networks so Postiz (which rides on Tailscale) can reach Temporal at temporal:7233.

Step 7: Bring It Up

# Make the directories Tailscale needs
mkdir -p tailscale-state tailscale-config

# Create the Tailscale serve config (edit the hostname!)
cat > tailscale-config/ts.json << 'EOF'
{
  "TCP": {
    "443": {
      "HTTPS": true
    }
  },
  "Web": {
    "postiz.YOUR-TAILNET.ts.net:443": {
      "Handlers": {
        "/": {
          "Proxy": "undefined"
        }
      }
    }
  }
}
EOF

# Start everything
docker compose up -d

Wait about 60-90 seconds for everything to initialize. Tailscale needs to authenticate, provision certificates, and report healthy. Postgres and Redis need to accept connections. Temporal needs to set up its schemas.

Watch the logs to see what's happening:

# Watch all services
docker compose logs -f

# Just Postiz
docker compose logs -f postiz

# Just Tailscale (see if it authenticated)
docker compose logs -f tailscale

Verifying Everything Works

1. Check Tailscale connectivity

docker exec postiz-tailscale tailscale status

You should see the container listed as online with your MagicDNS name.

2. Check Postiz health

curl -I undefined

Should return HTTP/2 200. If it hangs, Tailscale isn't online yet — check the logs.

3. Open it in your browser

Navigate to undefined. You should see the Postiz login page. Register your admin account.

Important: After registering, immediately add your social platform integrations from the dashboard. The platform API keys you put in docker-compose.yaml enable backend communication, but you still need to connect each platform through the UI.

The Complete Gotcha List

Gotcha	Symptom	Fix
Missing `/api` in `NEXT_PUBLIC_BACKEND_URL`	Dashboard loads but no data, 404s in console	Add `/api` suffix
Wrong `BACKEND_INTERNAL_URL`	OAuth callbacks fail, uploads silently break	Set to `http://localhost:3000`
`RUN_CRON` not set	Scheduled posts never publish	Add `RUN_CRON: 'true'`
`MAIN_URL` ≠ `FRONTEND_URL`	CORS errors, cookie issues	Make them identical
Tailscale healthcheck too aggressive	Postiz starts before Tailscale is ready	Increase `start_period` to 60s
Port 5000 exposed directly	Bypasses Tailscale entirely	Comment out/remove `ports` from Postiz
Temporal not running	Scheduling silently fails	Ensure `TEMPORAL_ADDRESS` points to the right container

Why Go Through All This?

You could use Postiz Cloud. It's great. But here's why I self-host:

Data ownership. Every API token, every scheduled post, every analytics data point lives on my server. Not someone else's.
No monthly SaaS fee. The only costs are my VPS and API usage. Postiz itself is free.
Tailscale means zero firewall configuration. I don't expose port 443 to the internet. I don't configure nginx. Tailscale's WireGuard tunnel handles all of it. My server could sit behind a NAT with no public IP and this would still work.
Platform API key security. All API keys live in environment variables on my server. They never touch Postiz's cloud. Given that these keys have write access to my social accounts, this matters.
Learning. Setting this up taught me more about Docker networking, Tailscale Serve, and Next.js deployment patterns than any tutorial could.

What's Next?

Now that Postiz is running, here's what I'm building on top of it:

Hermes Agent integration: An AI agent that drafts posts using my voice, uploads them via the Postiz CLI, and schedules them. Zero manual posting.
Analytics pipeline: Postiz's built-in analytics fed into a dashboard that tracks what's working across platforms.
Multi-user setup: Adding collaborators through Postiz's team features, all behind the same Tailscale barrier.

What about you? Are you self-hosting your social media tooling, or do you trust the cloud providers? I'm genuinely curious — every self-hoster I've met has a story about the one time their config broke at 2 AM. Drop yours in the comments.

DEV Community: Aryan Iyappan

96.2% vs 6.9% — I Watched 5 Frontier LLMs Fail at Sudoku While an Energy-Based Model Solved It in 0.24s

I Watched 5 Frontier LLMs Fail at Sudoku While an Energy-Based Model Solved It in 0.24 Seconds

The Architecture Problem Nobody Is Talking About

How LLMs Reason — And Why They Hit a Wall

How Energy-Based Models Reason — And Why It's Different

The Bigger Picture: Aleph and PutnamBench

LeCun's Bet — And Why It Matters

Why This Matters for Developers

Try It Yourself

How I Self-Hosted Postiz with Tailscale (and the Env Vars the Docs Don't Tell You About)

How I Self-Hosted Postiz with Tailscale (and the Env Vars the Docs Don't Tell You About)

What We're Building

Prerequisites

Step 1: Get Your Tailscale Auth Key

Step 2: Clone the Postiz Docker Compose Repo

Step 3: The Tailscale Service (This Is the Secret Sauce)

The Tailscale Serve Config

Step 4: The Postiz Service — Env Vars That Actually Matter

The Env Vars That Cost Me an Afternoon

1. BACKEND_INTERNAL_URL: 'http://localhost:3000'

2. NEXT_PUBLIC_BACKEND_URL MUST end with /api

3. MAIN_URL and FRONTEND_URL must be identical

4. RUN_CRON: 'true'

5. NOT_SECURED: 'false'

Step 5: The Supporting Cast (PostgreSQL, Redis, Temporal)

Step 6: Networks and Volumes

Step 7: Bring It Up

Verifying Everything Works

1. Check Tailscale connectivity

2. Check Postiz health

3. Open it in your browser

The Complete Gotcha List

Why Go Through All This?

What's Next?

1. `BACKEND_INTERNAL_URL: 'http://localhost:3000'`

2. `NEXT_PUBLIC_BACKEND_URL` MUST end with `/api`

3. `MAIN_URL` and `FRONTEND_URL` must be identical

4. `RUN_CRON: 'true'`

5. `NOT_SECURED: 'false'`