Auto-posting on Instagram, taken seriously, is a 344-line Python file.

What the code actually looks like

This is the Instagram-talking part of mixer/post_to_ig.py in S4L's repo, lightly trimmed. It is intentionally boring.urllib.request for HTTP, hmac for the proof, a while loop for the poll. The whole file (344 lines) adds the GCS upload, env loading, Postgres write-back, and CLI flags around this core.

# /Users/m13v/social-autoposter/mixer/post_to_ig.py  (excerpt, lines 117-172)
#
# The full Instagram-side of the pipeline. Three HTTP calls, one
# polling loop, no browser, no third-party SDK. The total file is
# 344 lines including GCS upload, Postgres write-back, and CLI flags.

GRAPH_BASE = "graph.instagram.com/v22.0"  # served over https

def appsecret_proof(token: str, secret: str) -> str:
    return hmac.new(secret.encode(), token.encode(), hashlib.sha256).hexdigest()

def ig_call(method, path, params, token, secret):
    proof = appsecret_proof(token, secret)
    params = {**params, "access_token": token, "appsecret_proof": proof}
    # ... urllib.request, returns parsed JSON

def ig_post_reel(user_id, token, secret, video_url, caption):
    # 1. create container
    c = ig_call("POST", f"/{user_id}/media", {
        "media_type": "REELS",
        "video_url": video_url,
        "caption": caption,
        "share_to_feed": "true",
    }, token, secret)
    cid = c["id"]

    # 2. poll status_code until FINISHED, deadline 300s
    deadline = time.time() + 300
    while time.time() < deadline:
        s = ig_call("GET", f"/{cid}", {"fields": "status_code,status,id"}, token, secret)
        if s.get("status_code") == "FINISHED":
            break
        if s.get("status_code") in ("ERROR", "EXPIRED"):
            raise SystemExit(f"container failed: {s}")
        time.sleep(5)
    else:
        raise SystemExit("timeout waiting for container")

    # 3. publish
    pub = ig_call("POST", f"/{user_id}/media_publish",
                  {"creation_id": cid}, token, secret)
    media_id = pub["id"]
    return ig_call("GET", f"/{media_id}",
                   {"fields": "id,permalink,media_type,timestamp"}, token, secret)

What goes in, what comes out

One fire of the auto-poster has five inputs on the left, gets funneled through one wrapper, and produces three concrete outputs on the right. The middle box is where every SaaS scheduler also sits, just hidden behind a UI.

One fire, end to end

The five steps a single launchd fire performs. Anything that should be a no-op is a no-op (the lock is taken, the queue is empty, dry-run is set). Anything that fails fails loudly and non-zero so launchd's stderr log catches it.

The cadence is one launchd plist

On macOS, the timer is a launchd plist with five StartCalendarInterval entries. On a Linux box you would use a systemd timer or a plain crontab line. There is nothing magical about the times themselves; they are the windows where our IG audience is awake. What matters is that they are spaced and that the plist is the only thing that drives a fire.

# /Users/<you>/Library/LaunchAgents/com.m13v.social-instagram-daily.plist
#
# The cadence. Five fires per day. Every fire runs run-instagram-daily.sh,
# which acquires a file lock, calls the picker, and posts one Reel.

<key>Label</key>
<string>com.m13v.social-instagram-daily</string>

<key>ProgramArguments</key>
<array>
    <string>/bin/bash</string>
    <string>/Users/&lt;you&gt;/social-autoposter/skill/run-instagram-daily.sh</string>
</array>

<key>StartCalendarInterval</key>
<array>
    <dict><key>Hour</key><integer>9</integer></dict>
    <dict><key>Hour</key><integer>12</integer></dict>
    <dict><key>Hour</key><integer>15</integer></dict>
    <dict><key>Hour</key><integer>18</integer></dict>
    <dict><key>Hour</key><integer>21</integer></dict>
</array>

What you get from a SaaS vs. what you get from doing it yourself

Both routes call the same Graph API endpoints. The difference is who owns the operational tax: token refresh, public-URL hosting, error logging, retries, and the picker logic that decides what goes out next.

Five details every SaaS hides from you

None of these are deal-breakers. All of them are the difference between a script that works the first time and a script that silently fails for two days before you notice.

How the 4:1 picker actually decides

The other half of auto-posting on Instagram is which file to post next. Most schedulers leave that to a human dragging things around a calendar. We use a deterministic sliding window:

• Read the last 5 rows of media_posts ordered by posted_at DESC.
• Count how many are tagged post_type='organic'.
• If that count is less than 4, the next pick is organic; otherwise product.
• Within that type, the picker takes the oldest status='draft' row.
• Output one JSON line: {post_type, video_path, post_number, reason, fallback}.

Over time the feed locks to exactly 4 organic + 1 product per 5 posts. The reason for the shape is human: a feed that is one in five product is still a creator feed; a feed that is one in two product is a sales feed and gets unfollowed. The whole picker is 114 lines of Python (scripts/ig_post_type_picker.py). It exits with code 2 when the queue is exhausted; the shell harness treats that as a clean no-op.

Who should actually write this themselves

Not everyone needs to. Here is the honest split.

• Solo dev or indie hacker shipping a product: write it yourself. The 344 lines are within the budget of an afternoon, you stop paying a per-seat scheduler fee, and the picker is whatever fits your content cadence.
• Marketing team posting from one brand account: probably not worth it. A SaaS scheduler is calling the same endpoints; you pay them so a non-engineer can drag a clip into a calendar slot. The math favors the SaaS.
• Agency posting on behalf of many clients: definitely not worth it. Hosted multi-account schedulers already solve the multi-token, multi-bucket, multi-locale problem. Recreating that yourself is a different job.
• Dev tool or open-source project: write it yourself, but optimize the rest of your distribution for Reddit and X. Instagram is rarely the channel where a technical audience finds new tooling. (S4L's actual product is the Reddit and X engagement loop; the IG poster is a side rail for our own brand presence.)