Skip to content
Charming Docs
Esc
↑↓navigate↵open⌘Jpreview
On this page

Remixing

Open a remixable app and get your own independent copy of its current code.

What you can do

Remix a shared app. If an app’s owner has turned remixing on, opening its URL gives you your own independent copy: separate storage, separate ownership, editable from the moment it’s created. Editing your copy never changes the original, and editing the original never changes copies already made. For the owner, remixing turns an app into a template: a way to hand out working copies without exporting and re-sending code by hand.

Try one. These apps are already remixable; open one and you get your own copy.

  • Hydration: tracks daily water intake against a goal.
  • Meals: logs meals and macros by day.
  • Flashcards: spaced-repetition flashcard decks.
  • Watchlist: movies and shows seen and to watch, with ratings.

Technical

The owner turns remixing on or off from the app’s settings page (a “Turn on remixing” toggle), or through an agent action.

Copy this prompt for your agent

Turn on remixing for one of my Charming apps so I can share it as a
template. Read https://charm.ing/docs/capabilities/remixing.md first.
List my apps and ask me which one, or if I've only got one, use that,
then turn on remixing and give me the public URL to share.

How an agent performs this job

To let visitors fork on their own, the owner calls set_remixable({ app_id }) (or PUT /app/<id>/remixable with {"remixable": true}), which returns the public_url to share. Anyone who opens that URL gets a fresh copy seeded from the template’s current source; reopening the same URL later resolves to the same visitor’s existing remix rather than minting a new one each time. unset_remixable (or {"remixable": false}) stops new visitors from forking; remixes already made keep working.

The contract

set_remixable and unset_remixable need a signed-in bld_user_* token belonging to the owner (or a team admin, for a team-owned app), not just edit access, so a collaborator can’t flip remixable state. An unclaimed (anonymous) app can’t be made remixable: set_remixable fails with anon_not_remixable until the app is claimed.

A remix copies the source, not the data: the new app starts with empty storage. Its version, capabilities, and stored module/ui/styles are independent of the template from that point on, so editing one never touches the other. Under the hood, a remix is created the same way exporting and forking an app’s source is: the visitor’s copy is seeded from a get_app_source-equivalent read of the template.

Limits, access, and deletion

  • What remixable exposes. Turning remixing on exposes the app’s current source to anyone who opens its URL, one fork per visitor, not the raw export endpoint. It doesn’t expose stored data: an app’s storage is never copied into a remix.
  • Idempotency. set_remixable and unset_remixable are both idempotent; calling either twice in the same state is a no-op.
  • Revocation and deletion. Turning remixing off (unset_remixable) stops new forks but doesn’t touch remixes already made; each keeps running as its own app. Deleting the original app doesn’t delete existing remixes, and deleting a remix doesn’t affect the original or other remixes.

Was this page helpful?