Studio is the simplest place to export a project. Use the command line when an agent, script, CI job, or advanced delivery workflow needs to control the render.
Render a normal video
From the project folder:
If you omit --output, HyperFrames writes the result under renders/.
The normal workflow is:
lint checks the project structure. check opens the project in a browser and looks for runtime, layout, motion, media, and contrast problems.
Examples:
GIF has no audio and limited transparency. Prefer MP4 or WebM for normal playback.
Choose quality and frame rate
The default standard quality is the right choice for most finished work.
Use a higher frame rate only when the source or destination needs it. It creates more frames, so rendering takes longer.
The CLI uses the composition’s data-fps when present and otherwise defaults to 30 fps.
Local or Docker
Local rendering is the normal choice:
It starts quickly and can use the computer’s browser GPU.
Use Docker when a controlled Chrome, FFmpeg, and font environment matters:
Docker adds startup and infrastructure overhead. It is useful for CI and repeatable production environments, not a requirement for every final render.
Render another composition
The root index.html is rendered by default. To target another standalone composition:
Nested compositions that use <template> wrappers should be rendered through the root composition that includes them.
Batch and cloud work
For several variable-driven versions, use batch rendering. For remote infrastructure, use HyperFrames cloud, AWS Lambda, or Google Cloud Run.
Those workflows involve output naming, credentials, concurrency, and infrastructure choices. Start in the CLI guide and use the complete CLI reference when you need every flag.
If rendering fails
Run:
Keep the first exact error rather than only the final “render failed” message. See Troubleshooting for the next checks.
Always watch the exported file itself. Preview proves that the project can play; the output file proves that the delivery is correct.
