Skip to content
LazyFrog

Bringing an app here, and taking it away

How to bring an app to LazyFrog (a git repository, a chat prototype or a live website) and how to take it with you if you leave.

  • A website, not a repository: site capture (see "Redesigning or moving an existing website"); import takes git repositories and a prototype's files, not addresses of websites.
  • A prototype made in the chat (a Claude artifact, a ChatGPT preview or Site): project import with source: {files}; see "Make it real: from a chat prototype to a project".
  • Import (project import, url of the repository): for an app made elsewhere (Lovable, Bolt, v0, Replit, Vercel, or any repository). It makes a new project, clones the repository, detects the framework, removes the other tool's editor plugins, turns vercel.json into routing.json, writes services.json, Dockerfile and compose.yml when missing, installs, starts the preview, scans once and commits. Follow the job: ready says whether it installed and answers (if not, the warnings say why; fix it before telling the user it works), and the result lists what changed, required_env (ask for these with secrets request), optional_env (features they can turn on later: don't ask for them all) and warnings to act on. Supabase and Firebase backends stay where they are. Public repositories on GitHub, GitLab and Bitbucket work on every plan. A folder link (…/tree/main/examples/blog) brings just that folder, as a project with a history of its own.
  • Someone else's open-source app (a theme, a starter): the result's licence says what the author allows. No licence means it isn't the user's to host publicly (ask the author); AGPL means offering the source to the site's users. Keep LICENSE and the author's credit. Then make it theirs: the site's address (https://<slug>.lazyfrog.app or their domain; a warning names the original's demo address when the configuration still has it), name, author, social and "edit on GitHub" links, and the example posts. The original stays as remote imported-from: git pull with remote: "imported-from" merges its updates later (a snapshot first; conflicts are listed in files the user changed). Run the tests and preflight after.
  • Export (project export): one archive with the code and its history, both databases as SQL, /data, the secret names (never values) and MOVING-OUT.md, a guide for running it elsewhere. The job's result has the download link (7 days). The user can also export from the portal (Project › Code, or Account › Data & privacy for everything).
  • Leaving LazyFrog: the export's MOVING-OUT.md is written for this app: its scheduled jobs, the paths that were behind a password (public elsewhere until protected again), the variables LazyFrog set (SITE_URL, TZ) and the platform services the code uses (email, PDFs, AI). Go through it with the user. The download link opens the live database to anyone who has it for 7 days, and it passes through this chat: delete it with project export_delete once it's downloaded. In order: export, check it runs elsewhere, move the domain, then cancel.

For your AI: this page as Markdown · llms.txt