Publishing, lovelycode docs

Publishing

Upload your files, connect GitHub or deploy from your build tools.

Send your finished website files to Lovelycode and they’re online. Updates become available as files arrive; removing a file removes it from the live site too. If your project needs a build, run it first and send the output.

Choose how to upload

Source	How it works	File editor
Drag and drop	Drop files or whole folders into the dashboard. A zip file is stored as a file, not unpacked, so drop the folder itself.	Stays editable
GitHub	Connect a repository and a branch. Every push to that branch updates the site.	Read only
Your own CI	Create a deploy key and have your pipeline send the build output as a zip.	Read only

With GitHub or a deploy key connected, make changes in your source project. Files in the dashboard are read only while that connection is active. Disconnect it to manage files in the dashboard again.

Versions

Each publish keeps a complete copy of your site as a version, and visitors always see one whole version at a time: a change with several files never appears half applied. The five most recent versions are kept, plus the one that is live, and they do not count toward your storage.

By default, the dashboard publishes a new version 20 seconds after your last change. You can pause the countdown and publish when you are ready, or turn automatic publishing off in your site’s settings. Changes then wait in a draft that only you can open, at an address the dashboard gives you, until you press Publish.

Open Versions in the dashboard to see every version, preview one, or restore one. Restoring makes that version live right away and puts its files back in your editor.
A draft or version preview address works for an hour from the moment the dashboard hands it to you, so you can share it with someone for a quick look.
GitHub syncs and deploys create versions too, so a bad push is one Restore away from being undone.

Upload from your computer

Open your site in the dashboard and drop in the files or folders. Put index.html at the top level. If you have a zip, unzip it first: dashboard uploads keep zip files as downloads rather than extracting them.

Connect GitHub

Choose GitHub in your site’s file source settings, then select a repository and branch. Push changes to that branch to update the site. The repository should contain files ready to serve; Lovelycode does not run a build. For projects that need one, use your build pipeline and a deploy key.

Deploying from your own CI

Create a deploy key in your site’s settings and store it as a secret in your CI system. Each key belongs to one site. If you need to replace it, your other sites keep their own keys.

The script below requests an upload URL, uploads a zip and applies the update. Zip the contents of your build folder so index.html is at the top level. Your site’s settings include a version filled in with its details.

deploy.sh

# Needs jq. Zip the CONTENTS of your build folder, so index.html is at the top.
(cd dist && zip -qr ../site.zip .)
SIZE=$(wc -c < site.zip)

# 1. Ask for a one-time upload URL. The size is signed into it, so it must be exact.
DEPLOY=$(curl -fsS -X POST https://lovelycode.app/api/v1/sites/$SITE_ID/deploys \
  -H "Authorization: Bearer $LOVELYCODE_DEPLOY_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"size\":$SIZE}")

# 2. Upload the archive straight to storage. Raw body, not multipart.
curl -fsS -X PUT "$(echo "$DEPLOY" | jq -r .deploy.upload_url)" \
  -H "Content-Type: application/zip" \
  --data-binary @site.zip

# 3. Publish. Unchanged files are skipped, files you removed are deleted.
curl -fsS -X POST https://lovelycode.app/api/v1/sites/$SITE_ID/deploys/$(echo "$DEPLOY" | jq -r .deploy.id)/commit \
  -H "Authorization: Bearer $LOVELYCODE_DEPLOY_KEY"

# A 429 or 409 means another deploy is too close or still running. Both are safe to
# retry after a few seconds; anything else will not improve with waiting.

On commit we compare the archive with what is already on the site. Files that have not changed are skipped, files you removed are deleted, and deploying an identical build changes nothing at all.