← All releases

Guildwise HQ 1.3.0

29 October 2026

Runner 0.1.62 (unchanged). The video schedule, Short destinations and worker roles. Migrations 2740 to 2742 and a data migration (`video-schedule-2026-10`). New optional environment variables `AOM_VIDEO_MAX_BYTES`, `AOM_VIDEO_ROLE`, `AOM_VIDEO_WORKER_TOKEN`, `AOM_VIDEO_WORKER_PORT`, `AOM_VIDEO_PUSH_URL` (now requires `AOM_VIDEO_WORKER_TOKEN`), `AOM_TIKTOK_CLIENT_KEY` and `AOM_TIKTOK_CLIENT_SECRET`.

Full changelog

Added

• Video worker roles: AOM_VIDEO_ROLE=render|publish|all (default all). A server that cannot render runs publish; a render worker elsewhere pushes each finished file over HTTPS to PUT /api/worker/video/renders/:id/files/:name (bearer AOM_VIDEO_WORKER_TOKEN, sha256 and size checked, served by the publish worker on AOM_VIDEO_WORKER_PORT, behind the reverse proxy) and a render counts as done only when every file is acknowledged. The video status reports render and publish heartbeats next to the combined worker. A rendered video whose file has not arrived yet is waited for until its slot instead of failing.
• YouTube videos: a publishing schedule (docs/BLOG-API.md "YouTube"). Per format (videos, Shorts) you tick the weekdays, the local time and the time zone (default Africa/Johannesburg, daylight saving handled) and the destinations; a video goes out at the next free slot. The writer's weekly limit is the number of days ticked, and it stops while twice a week's slots wait in review or are scheduled. Slots are managed with new calls: schedule, unschedule, move, swap, preview and GET /slots under /api/platform/video.
• Destinations for Shorts: YouTube, Facebook (Reels), Instagram (Reels), X, LinkedIn, Bluesky and TikTok can be chosen in the schedule and per video, with a caption each (the drafter can supply default captions with the video; no caption carries a link). The publish worker posts each at the slot with back-off until 6 hours after it, then marks the destination failed and mails you; one failed destination can be retried on its own (POST /api/platform/video/posts/{id}/shares/{network}/retry, the Queue shows a button per failed destination). Instagram and TikTok are channels in Social sharing but not share networks of the blog. TikTok connects with OAuth (AOM_TIKTOK_CLIENT_KEY, AOM_TIKTOK_CLIENT_SECRET), posts from a signed temporary media URL (GET /api/public/video-media/...), needs your privacy choice and consent for every post, and posts privately until you tick that the app passed TikTok's audit. X video uses OAuth 1.0a and may need an OAuth 2.0 token (see docs/BLOG-API.md). The status strip names the render and publish workers separately.
• Events VideoPostScheduled, VideoPostUnscheduled and VideoPreviewRequested; VideoPostApproved no longer needs a render. A missed slot (not rendered 30 minutes before it) slips to the next free slot, and the super admins are mailed about it, about an offline render worker, a render that failed, an empty slot and a full video disk.

Changed

• YouTube videos: the script is the review gate. Submitting or editing a script no longer renders anything; Schedule (the old Approve) gives the video its slot and the render starts renderLeadHours before it (48 hours for videos, 24 for Shorts), or at once for "publish now". A "Preview render" (one of the 3 renders) shows the video before you schedule it. YouTube publishes at the slot itself (publishAt); the limit of one upload a day is gone (one upload runs at a time).
• Storage of rendered videos: the MP4 is removed after publishing (every destination sent or skipped and the video public, or 6 hours after the slot), 3 days after a failed destination, 1 day after a rejection, 7 days after a preview in review nobody touched. A retry of a failed upload renders again. AOM_VIDEO_MAX_BYTES (default 5 GB) stops new renders when the disk budget is used.
• Settings perWeek and shortsPerWeek are replaced by schedule; until one is saved it is derived from them (3 and 3 give Monday, Wednesday and Friday at 10:00 for videos, Tuesday, Thursday and Saturday at 16:00 for Shorts).
• X: a refused video upload (401 or 403 from the media endpoints) fails that Short's X share only and no longer pauses the X channel, so articles keep posting.
• A Preview render runs while no YouTube channel is connected yet (it uploads nothing); scheduled renders still wait for the channel.
• The test suite no longer flakes under load: the media proxy's body watchdog takes an injectable clock (default Date.now, no behaviour change).
• Existing videos are brought over by the data migration: approved videos keep the slot they have on YouTube, ones still waiting get the next free slot, finished renders of videos in review become previews, and unfinished renders are dropped (they render when you schedule the video).

Fixed

• A video that is not rendered 30 minutes before its slot slipped twice when the app and the worker noticed at the same time; the slip now re-checks under the slot lock. A YouTube publishAt is at least 15 minutes ahead (otherwise the video goes public at once) and is worked out again on a retry; a post moved or unscheduled just as its upload started is not uploaded with the old slot. Two render workers can no longer both claim a render. A re-flow no longer moves posts that are rendered, close to their render, or already on a slot of the schedule. Moving a post respects the normal minimum lead time. Unscheduling clears the TikTok options and the captions edited at scheduling. Scheduling a TikTok Short without options is refused. Share links in the video pages are shown only for https addresses. The server refuses to start with AOM_VIDEO_PUSH_URL and no AOM_VIDEO_WORKER_TOKEN; a 0-byte artifact is accepted by the push; stale push temp files are cleaned up; the data migrations take a database lock so two instances do not run them at once.
• Short destinations never post twice: a destination with saved progress counts as started (unschedule, move, slip and re-flow are refused), the request that publishes is not repeated blindly when its answer is lost, X's duplicate-content 403 no longer pauses the channel, a retry keeps TikTok's publish id, TikTok token renewals and callback states are serialized and single-use, upstream-provided upload addresses are checked against the network's hosts, disconnecting TikTok revokes its token, and an upload that ends after its slot is made public.