Auto Media Publisher

03.2026 - ongoing - Last updated Aug 22nd, 2026

Auto Media Publisher is a desktop tool that streamlines publishing workflows for recurring recorded content, automating video processing and YouTube publishing while supporting shared organization workspaces and role-based access.

Desktop Guide

1. Download
2. Initial Setup
3. Features

Download

Download the latest release from: https://github.com/kylezhao101/auto-media-publisher/releases/latest

• Windows: AutoMediaPublisher-Setup-[latest].exe
• Mac: AutoMediaPublisher-[latest]-arm64.dmg

Because I'm not paying for an Apple Developer account, the Mac version is not signed and will require you to bypass security settings to run the application.

The command is:

xattr -cr /Applications/AutoMediaPublisher.app

Or xattr -cr [path to app] if you installed it somewhere else.

Organization Setup

Organization members do not need to import personal Google Cloud credentials when publishing through an organization's connected YouTube channel.

Organization owners and administrators can:

• Create and manage organization workspaces
• Invite members by email
• Assign role-based permissions
• Connect a shared YouTube channel
• Create shared publishing presets

Once invited, members can sign in and switch between Personal and Organization workspaces directly from the desktop application.

Personal Setup

If you already have a gcp project and credentials, you can skip steps 2-6 and just import your existing credentials JSON file in step 7.

1. Download and run the installer.
2. Create a Google Cloud project.
3. Enable the YouTube Data API v3.
4. Navigate to Credentials → Create Credentials → OAuth Client ID.
5. Select Desktop App as the application type.
6. Download the OAuth client credentials JSON file.
7. Open Auto Media Publisher and click on Import Credentials.
8. Choose the downloaded credentials JSON file.
9. Click Connect YouTube, when prompted on a browser window, authorize the Google account associated with your channel.

A Google Cloud project and YouTube Data API credentials are required because uploads are performed directly through the official YouTube API on behalf of your channel.

Once configured, subsequent uploads only require selecting your media files, entering metadata, and clicking Publish.

If you want to manually drag in your credential files, naming is as follows:

• Mac:
  • ~/Library/Application Support/AutoMediaPublisher/google-token.json
  • ~/Library/Application Support/AutoMediaPublisher/gcp-token.json
• Windows:
  • %APPDATA%\Roaming\AutoMediaPublisher\google-token.json
  • %APPDATA%\Roaming\AutoMediaPublisher\gcp-token.json

Features

• Process multiple media clips through a one-click FFmpeg rendering, audio processing, and YouTube publishing workflow
• Run long-running media processing in background Python workers with real-time progress updates
• Configure video titles, descriptions, custom thumbnails, visibility, and playlists
• Select CPU or GPU hardware acceleration and processing performance
• Switch between Personal and Organization publishing workspaces
• Create and manage organizations with owner, admin, publisher, and member roles
• Invite organization members through email with role-based access control
• Create and share organization publishing presets
• Connect and manage shared organization YouTube channels
• Publish to organization channels without distributing long-lived Google credentials to members
• Receive desktop notifications for completed uploads and warnings
• Automatically update Windows installations
• Track organization activity through an audit log of member, preset, invitation, and YouTube connection changes

Project Overview

Auto Media Publisher is a desktop application that automates the process of preparing and publishing long-form media content to online platforms. Originally developed for my church's weekly video publishing workflow, the application reduced a roughly 1.5-hour manual process involving video preparation, editing, and uploading into a largely one-click workflow for non-technical users.

The current application combines an Electron/React desktop interface with a Python media-processing worker and a deployed FastAPI/Supabase backend. Personal publishing remains local-first, while organization workspaces provide shared presets, role-based access, invitations, and centrally managed YouTube connections for team workflows.

The project originally began as a cloud-based media processing platform hosted on Azure using student credits. However, because recordings frequently exceeded tens of gigabytes and required long-running video processing workloads, cloud hosting costs and storage limitations quickly became impractical. The system was subsequently redesigned into a desktop-first application that leveraged local compute resources while preserving many of the automation features developed in the original cloud architecture.

Problem

Publishing recorded services involved several manual steps:

• Exporting and transcoding large video files
• Creating thumbnails
• Entering titles and descriptions
• Uploading videos
• Monitoring upload progress
• Managing errors and failed uploads

This process was time-consuming and difficult to delegate to volunteers with varying technical backgrounds.

How might we reduce the technical overhead of publishing media content while making the workflow accessible to non-technical users?

Requirements

1. Support large video files (including MXF recordings)
2. Provide a simple guided workflow
3. Display processing progress and status updates
4. Automatically generate publish-ready assets
5. Continue functioning on a standard consumer PC
6. Handle failed processing gracefully
7. Minimize user interaction

Desktop Implementation

The application follows a job-based processing pipeline:

1. Select video files and thumbnail
2. Enter metadata such as title and description
3. Launch a background processing job
4. Transcode and prepare media assets using FFmpeg
5. Upload assets and monitor publishing progress
6. Surface warnings, errors, and completion status to the user

The desktop interface is built with Electron and React, while media processing is delegated to a Python worker process. Long-running tasks execute independently of the user interface and communicate progress updates back to the renderer through IPC events. This architecture keeps the application responsive even when processing multi-gigabyte video files.

Organization Workspaces

The desktop application also supports shared organization workspaces for teams managing a common YouTube channel. While personal publishing keeps Google credentials locally on the user's device, organization workspaces use a deployed FastAPI and Supabase/PostgreSQL backend to manage shared state and authentication.

Organizations support:

• Owner, admin, publisher, and member roles with role-based access control

• Email-based invitations and member management

• Shared publishing presets

• Organization-level YouTube connections

• Shared playlist access and publishing permissions

  

Organization invitations are delivered by email through Resend. After accepting an invitation through the web application, users can sign in to the desktop app and access the shared workspace based on their assigned role.

YouTube authentication is handled differently for personal and organization publishing. Personal credentials remain on-device, while organization refresh tokens are encrypted with Fernet before being stored server-side. For organization uploads, the backend exchanges the stored refresh token for a short-lived Google access token, so the desktop worker never receives the organization's long-lived credential.

Organization actions are recorded in an audit log to provide visibility into changes made within a shared workspace. Events such as invitations, role changes, preset updates, and YouTube connection changes record the actor, timestamp, action, and relevant context.

Cloud Implementation

The project originally began as a cloud-based media processing platform built on Azure. The system was designed around asynchronous job processing to support large media uploads and long-running transcoding tasks.

Media files and generated assets were stored in Azure Blob Storage, while job requests were submitted through a FastAPI backend and processed by background workers. Azure Queue Storage was used to decouple the user interface from video processing workloads, allowing uploads, transcoding, thumbnail generation, and publishing operations to execute independently. Job progress and status updates were streamed back to the dashboard to provide real-time feedback.

The architecture was intentionally designed around distributed services to improve scalability and fault tolerance. However, because weekly recordings frequently exceeded tens of gigabytes, storage and compute costs quickly became impractical under student cloud credits. This ultimately motivated a redesign into a desktop-first application that leveraged local compute resources while preserving much of the original job-based workflow.