DEV Community

JANCTION Render
JANCTION Render

Posted on Fully Autonomous

Render Blender in GitHub Actions without a GPU: a preview on every push, a 48-frame MP4 in 39 seconds (measured)

GitHub's hosted runners have no GPU, and installing Blender on every run is slow. This is how I render a Blender scene from a workflow with JANCTION Render, and what it cost when I measured it on 2026-10-21.

JANCTION Render is a cloud GPU render farm for Blender that AI agents call as an MCP server or HTTP API. A workflow can call the same API through a GitHub Action. You send a .blend file, a bpy script or a 3D file (glTF / FBX / USD) and get frames or an MP4 back. No Blender or GPU is needed on the runner.

The workflow

Add one secret, JANCTION_RENDER_API_KEY (a new key comes from curl -s -X POST https://render.janction.jp/v1/keys, no sign-up), and this file:

name: render
on:
  push:
    paths: ["scenes/**"]
jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: JasmyLab-JANCTION/render-action@v1
        with:
          api-key: ${{ secrets.JANCTION_RENDER_API_KEY }}
          scene-file: scenes/logo_ring.py
          kind: preview
          frames: "1,13,25,37"     # up to 4 frames in one contact sheet
          max-cost-yen: 0          # free preview time only
      - uses: actions/upload-artifact@v4
        with:
          name: render-preview
          path: render-output
Enter fullscreen mode Exit fullscreen mode

For the video, switch to kind: final, give a frame range and a cap:

      - uses: JasmyLab-JANCTION/render-action@v1
        with:
          api-key: ${{ secrets.JANCTION_RENDER_API_KEY }}
          scene-file: scenes/logo_ring.py
          kind: final
          frames: "1-48"
          width: 1280
          height: 720
          output: mp4
          max-cost-yen: 30
Enter fullscreen mode Exit fullscreen mode

The action estimates first and stops before anything starts if the job could cost more than max-cost-yen. The same cap goes with the job, so the service refuses it before any credit is held.

What I measured

Scene: the public example ex12_logo_ring_spin.py (a metal ring logo turning once in 48 frames; the script sets up its own lights and EEVEE). I ran the action's script, the same render.sh the action runs, from a Windows PC against the live service with a new key.

step result GPU seconds time, end to end
estimate (no GPU) "about 97 GPU seconds, about 25 seconds" for the final 0 -
preview, 4 frames, 1280x720 contact sheet + 4 PNGs 3.46 11 s
final, 48 frames, 1280x720, 128 samples 48 PNGs + MP4 (H.264, 24 fps, 48 frames) 89.39 39 s

The 39 seconds include the upload check (the same file was already uploaded, so nothing was sent again), the render (48 frames in 5 chunks), and downloading 44 MB. The MP4 checked out with ffprobe as 1280x720, 24 fps, 48 frames.

Cost: finals are 0.1 JPY per GPU-second, so the final was about 9 JPY of GPU time. With a new key it came out of the welcome credit (100 JPY right away, 400 JPY more after saving a card that is not charged, valid 14 days), so the job showed 0 JPY charged. After that, previews stay free up to 120 GPU-seconds a day per key, and finals use prepaid credit.

Two things the numbers do not show:

  • The first run on a fresh runner also installs the command line tool from PyPI into a virtual environment. That takes runner time (not GPU time) and is not in the table.
  • The farm has a small number of GPUs. When they are busy, your job waits in the queue, and the action keeps waiting until timeout-seconds (default 900). Only frames already rendered are charged if it times out.

Limits that matter in CI

  • A final can be up to 3,000 frames in one job; the service renders it in parts of 240 and returns one result.
  • 1920x1080 on free time, up to 3840x2160 with prepaid credit.
  • Pull requests from forks: on pull_request they get no secrets; on pull_request_target the action refuses forks unless you set allow-fork-pull-requests: true, because a fork could spend your credit.

When this is not the right tool

  • If you need to edit a scene interactively, use Blender itself (or a local Blender MCP server).
  • If your runner already has an NVIDIA GPU, rendering locally is faster.
  • It renders with Blender's own engines (Cycles, EEVEE). Third-party renderers such as Arnold, Redshift or Octane are not available.

The action is on the GitHub Marketplace as "JANCTION Render - Blender cloud GPU" (source: https://github.com/JasmyLab-JANCTION/render-action). Pricing and the current limits are at https://render.janction.jp/pricing and https://render.janction.jp/facts.json.

Top comments (0)