Videola #2245

Name of the Script

Videola (videola.sh)

Script Type

CT (LXC Container)

Does this script support arm64?

arm64 not tested — the server bundle is plain JavaScript on Node 22 with no native addons and no
per-architecture asset, so it should not care, but I only have an amd64 host to test on.

📋 Script Details

What it is: a video editor that runs in a browser. Import footage, cut it on a timeline, keyframe
anything, grade it against real scopes, mix the sound to a loudness target and export an MP4 — with
the project model, the command bus and the file format in a Rust core compiled to WebAssembly, and
nothing uploaded anywhere. Also templates that bake into ordinary editable projects, motion blur
averaged over eight real instants of a shutter, spectral noise reduction, 5.1 surround with a position
per track, scene detection, an HTTP API and an MCP server. GPL-3.0, and I am its developer.

• Source: https://github.com/fgilde/videola · site https://videola.app/
• Releases: https://github.com/fgilde/videola/releases

The scripts are written and tested. Pull requests from forks are not open on this repository, so
they are on a branch instead — ready to be pulled in as-is or picked apart:

https://github.com/fgilde/ProxmoxVED/tree/videola → ct/videola.sh, install/videola-install.sh,
json/videola.json
(diff: main...fgilde:ProxmoxVED:videola)

How it installs: bare metal, no Docker. Each release publishes a Node server bundle, so it is
NODE_VERSION="22" setup_nodejs, then
fetch_and_deploy_gh_release "videola" "fgilde/videola" "prebuild" "latest" "/opt/videola" "videola-server-*.tar.gz",
one systemd unit and one generated token. Port 7331, Debian 13, unprivileged, updateable: true
through check_for_gh_release, with create_backup / restore_backup around the update. Projects and
imported media live in /opt/videola_data, so an update keeps them.

Why the installer generates a token: every /api call carries it as Authorization: Bearer, and
the server refuses to listen on anything but loopback without one — an install with no token would not
serve at all. It is written once and kept, because regenerating it on an update would lock out every
client that stored it, and it is dropped in ~/videola.creds.

Tested on real hardware (Proxmox VE 8.2.2, kernel 6.8.4-2-pve):

• Full run of ct/videola.sh: container created, release 0.9.1 fetched, service created,
  Completed Successfully.
• http://<ip>:7331/ → 200 and the editor loads · /api/health without the token → 401 · with the
  generated token → 200 and {"ok":true,"storageRoot":"/opt/videola_data/storage"} ·
  systemctl is-active → active.
• Worth knowing for older hosts: that host refuses to create a Debian 13 container
  (unsupported debian version — its LXC stack predates the template), so the verified run used
  var_version=12. The script keeps 13 as the default, per the guidelines.
• The test container was destroyed afterwards and the host left as it was found.

Note on resources: the defaults are 2 cores / 2 GB / 10 GB. Export encodes on the CPU, and video
fills a disk quickly — more of both is better for real footage; there is no GPU path.

Written with AI assistance and reviewed against AGENTS.md: Claude Opus 5 (Claude Code), high
reasoning effort. What the review changed: a hand-written curl became fetch_and_deploy_gh_release, a
hand-written version check became check_for_gh_release, and the env file moved out of /opt/videola
so an update cannot take the token with it.

One thing stated plainly: the app is actively maintained and publishes official release tarballs,
but it is not 6 months old and has nowhere near 600 stars — first release August 2026. If that
alone closes this, no hard feelings; the branch is there if you would rather keep it for later.