---
title: Cloud rendering
description: Render on HeyGen's managed cloud without deploying your own infrastructure.
---

Use managed cloud rendering when you want a finished file without installing Chrome or FFmpeg or maintaining AWS or Google Cloud infrastructure.

## Render a project

Sign in once, then render the current project:

```bash
hyperframes auth login
hyperframes cloud render
```

The command packages the project, uploads it, waits for the render, and downloads the finished file to `renders/`.

Choose a composition or output path when the defaults are not right:

```bash
hyperframes cloud render . \
  --composition compositions/intro.html \
  --output renders/intro.mp4
```

For CI or another headless environment, save a long-lived API key instead:

```bash
echo "$HEYGEN_API_KEY" | hyperframes auth login --api-key
```

See [Authentication and API keys](/guides/authentication) for credential precedence and local alternatives.

## Choose the output

| Option | Values | Default |
| --- | --- | --- |
| `--fps` | 1–240 | `30` |
| `--quality` | `draft`, `standard`, `high` | `standard` |
| `--format` | `mp4`, `webm`, `mov` | `mp4` |
| `--resolution` | `1080p`, `4k` | `1080p` |
| `--aspect-ratio` | `16:9`, `9:16`, `1:1` | detected from a local composition when possible |

```bash
hyperframes cloud render --quality high --fps 60
hyperframes cloud render --resolution 4k
```

<Warning>
  4K is billed at 1.5× and supports MP4 only. WebM and MOV use the alpha-capable path, which does not support 4K supersampling.
</Warning>

## Check what will upload

Cloud project archives have a 200 MB limit. Inspect the archive before starting a render:

```bash
hyperframes cloud render --dry-run
```

Add generated or unnecessary files to `.hyperframesignore` when needed:

```gitignore
/exports/
/source-masters/
```

Do not exclude media that the composition needs at render time. HyperFrames already omits common development and generated paths, including `.git`, `node_modules`, root-level `renders/`, and root-level `snapshots/`.

## Fill template variables

Use the variables declared by the composition:

```bash
hyperframes cloud render \
  --variables '{"title":"Q4 recap","theme":"dark"}' \
  --strict-variables
```

For larger payloads, pass a JSON file with `--variables-file`.

The first `hyperframes cloud render` that uploads a local project prints an `asset_id`. Reuse it to
render the same uploaded project with different values:

```bash
hyperframes cloud render \
  --asset-id asst_abc123 \
  --variables '{"title":"Customer update"}'
```

## Run asynchronously

Submit without waiting and receive a webhook when the render finishes:

```bash
hyperframes cloud render \
  --callback-url https://example.com/hyperframes-hook \
  --no-wait
```

Then inspect or manage renders by ID:

```bash
hyperframes cloud list
hyperframes cloud get hfr_abc123
hyperframes cloud delete hfr_abc123
```

For automated retries, pass a stable `--idempotency-key` so an interrupted request can be replayed safely.

## Choose another renderer

- Use [`hyperframes render`](/guides/rendering) while authoring or when the machine running the command should do the work.
- Use [AWS Lambda](/deploy/aws-lambda) or [Google Cloud Run](/deploy/gcp-cloud-run) when you need to own the rendering infrastructure.
- Use a [deployment template](/guides/deploy) when you need a working hosted starting point rather than the full distributed-rendering stack.

See the [CLI reference](/packages/cli#hyperframes-cloud) for every flag and JSON output shape.

## Related topics

- [Compare every rendering path](/deploy/overview)
- [Render locally from the CLI](/guides/rendering)
- [Operate rendering in your own cloud account](/deploy/aws-lambda)
