---
title: "Profiles"
description: "Export your workspace under profiles/your-nick, share via PR, import other people's brand-persona-ref kits."
---

A profile is a committed dump of your workspace — your brands, personas, references, templates, and (optionally) renders — packaged under `profiles/<your-nick>/` for sharing via PR. The model is "portable identity": the brand voice you tuned, the personas you built, the reference plates you locked, the templates you extracted from your wins, all bundled in one folder that other Ralphy users can clone, import, and extend. Profiles are how the community grows; they're also how you carry your setup between machines without losing the master shots.

## What lives in a profile

`profiles/<nickname>/` mirrors the layout of `.ralphy/` but selectively. The export defaults skip renders and intermediate video clips because those are heavy and rarely useful to a recipient. You can include them with a flag if you want a fully-reproducible PR.

| Folder | In default export? | Notes |
|---|---|---|
| `brands/` | Yes | Logo, palette, tone, default persona pointer |
| `personas/` | Yes | Archetype, voice id, master shot |
| `references/` | Yes | Pulled URLs, design tokens, blueprints |
| `templates/` | Yes | Workspace-local templates you extracted |
| `projects/` | Yes (metadata + scenarios + manifests) | Logs and `.json` files; renders stripped by default |
| `projects/*/render/` | No (default) | Final mp4s. Add with `--include-renders`. |
| `projects/*/assets/*.mp4` | No (default) | Intermediate video clips. Add with `--include-videos`. |
| `.ralph/asset-cache/` | No | Auto-pulls from `ralphy-assets` companion repo on import |

The reasoning: most of what makes a profile useful (the persona master shot, the brand tone, the template you tuned) weighs kilobytes. The renders and intermediate clips weigh megabytes-to-gigabytes and the recipient can re-render from the manifest. Heavy by default would make PRs unreviewable.

## Exporting

```bash
ralphy profile export alex \
  --include-renders \
  --dry-run
```

The dry-run prints exactly what would be copied without writing. Drop `--dry-run` to actually copy `.ralphy/` → `profiles/alex/` and commit the result to git. The export is non-destructive — your data root stays as it is.

<ParamField path="<nickname>" type="string" required>
  Your nick. Becomes the folder name under `profiles/`.
</ParamField>

<ParamField path="--include-renders" type="boolean">
  Include `render/final.mp4` and other render outputs. Heavy; opt in.
</ParamField>

<ParamField path="--include-videos" type="boolean">
  Include every `.mp4` and `.mov` under projects. Heaviest; opt in only for full repro packs.
</ParamField>

<ParamField path="--dry-run" type="boolean">
  Print what would be copied; do not write.
</ParamField>

The exported folder also gets a `PROFILE.md` summarizing what's inside — brand count, persona count, template count, project count with statuses. Read it with `ralphy profile show <nick>`.

## Importing someone else's profile

```bash
ralphy profile import alex
```

The import is **additive by default**. It merges `profiles/alex/` into your local `.ralphy/`, but it will not overwrite files that already exist locally. Collisions get skipped with a stderr warning so you can resolve them by hand. The registry (the central index of brands, personas, projects) gets merged too — every entity in the imported profile shows up in your `ralphy brand list`, `ralphy persona list`, and so on.

<ParamField path="<nickname>" type="string" required>
  The nick under `profiles/` to import from.
</ParamField>

<ParamField path="--overwrite" type="boolean">
  Replace existing local files instead of skipping. Use when you want a hard reset to someone else's setup.
</ParamField>

<ParamField path="--dry-run" type="boolean">
  Print what would be copied; do not write.
</ParamField>

<Warning>
  `--overwrite` is destructive. It violates the usual append-only contract because you've asked for it explicitly. Run with `--dry-run` first and confirm the file list before re-running for real.
</Warning>

## Listing and inspecting

```bash
ralphy profile list -p
```

```text
┌──────────┬──────────┬─────────┬────────────┐
│ nickname │ brands   │ persons │ templates  │
├──────────┼──────────┼─────────┼────────────┤
│ alex     │ 3        │ 5       │ 7          │
│ kate     │ 1        │ 2       │ 12         │
│ pavel    │ 4        │ 8       │ 3          │
└──────────┴──────────┴─────────┴────────────┘
```

`ralphy profile show <nick>` prints the profile's `PROFILE.md` so you can read the description before importing.

## Sharing via PR

The whole point of `profiles/` being a committed folder is that it travels through git. Typical share workflow:

1. `ralphy profile export <your-nick>` to land everything under `profiles/<your-nick>/`.
2. Review the diff. Check that no `.env`, no API keys, no PII slipped in. (The export is selective about `.env` files, but a manual sanity check costs nothing.)
3. `git add profiles/<your-nick>/` and commit.
4. Push and open a PR on the [`ugc-cli`](https://github.com/alecs5am/ralphy) repo.
5. Once merged, other users can `git pull` and `ralphy profile import <your-nick>` to grab your setup.

Profiles intentionally do not vendor heavy assets — those live in the [`ralphy-assets`](https://github.com/alecs5am/ralphy-assets) companion repo, which Ralphy auto-pulls on import via the SHA-256-verified asset cache at `.ralphy/cache/assets/`. Your PR stays small; the heavy assets stay where they belong.

## Why profiles exist

Three reasons, in order of how often each one bites:

- **Portability between machines.** You set up Ralphy on your laptop, you tuned a persona for three months, the laptop dies. Without a profile, you'd start from scratch. With a profile committed to your fork of `ugc-cli`, you `git pull` and `ralphy profile import <your-nick>` on the new machine and you're back.
- **Team sharing.** Two creators on the same team share a brand and a persona. One exports a profile; the other imports it. Both teammates' projects pick up the brand's palette and tone without retyping.
- **Community templates with provenance.** When you extract a template from a successful project (`ralphy template create --from-project <id>`), the template lives under `.ralphy/workspaces/default/templates/`. Bundle it into your profile and the community can `import` your workflow with the master shots intact — not just the template definition. That's why the showcase projects under [`ralphy-assets`](https://github.com/alecs5am/ralphy-assets) ship as profiles, not just templates.

## What profiles are not

A profile is not a backup tool. It captures the durable parts of your workspace — the entities you'd want to recreate. It does not capture in-flight renders, daemon job queues, or local-only scratch files. For real backup, use whatever you use for the rest of your dotfiles.

A profile is also not a permission grant. Importing someone's profile gives you their brand and persona definitions, not their API keys. You need your own `OPENROUTER_API_KEY` and `ELEVENLABS_API_KEY` to actually generate anything (see [Setup and doctor](/cli/setup-doctor)).

## Related

- [Batches](/working/batches) — a common source of profile-worthy outputs
- [Brands, personas, refs](/working/brand-persona-refs) — the entities profiles carry
- [Templates concept](/concepts/templates) — workspace-local templates ship via profiles
- [`cli/commands/profile.ts`](https://github.com/alecs5am/ralphy/blob/main/cli/commands/profile.ts) — source of truth
- [`ralphy-assets`](https://github.com/alecs5am/ralphy-assets) — companion repo for heavy assets
