Overview
I'm volunteering to implement this if the approach looks right/there isn't already the functionality another way.
Let me know if you'd like any changes to the design, I will try and look to implement something over the coming weekend.
Feature
remove stale hosted assets without clearing the entire deployment
Problem
juno hosting deploy is diff-based and only uploads changed files, this is great.
But there's no way to remove files from a live satellite that are no longer in the current build output, without running juno hosting clear (which wipes everything and re-certifies the full site).
For large sites this is painful:
--clear re-commits all files in a single proposal, hitting the ICP 40B instruction limit on sites >~80 MB
- There's a downtime window between the clear and the new deploy applying
- In the example of An Astro/Vite frontend, the stale files accumulate because Vite content-hashes filenames — old chunks (
main.abc123.js) are never overwritten, only orphaned.
Proposed Solution
juno hosting prune
A new subcommand that removes files present on the satellite but absent from the current build output — without touching files still in use.
juno hosting prune [options]
Options:
--dry-run: Show what would be deleted without deleting
--mode: Environment to target (production, staging, development)
-h: --help Output usage information
Algorithm
A work-in-progress, but I'm thinking something like this;
- Scan local
source directory (from juno.config) → local_files
- Fetch live asset list from satellite →
live_files
- Compute
stale = live_files − local_files
- Delete
stale via change proposal (same mechanism as [deploy]
I'm thinking it would be the inverse of the current deploy's skip logic
- skips:
hash(local) == hash(live)
prune deletes: live_file ∉ local_files
Zero Downtime
Only orphaned files are removed.
The satellite always serves a valid, complete set of assets. No window where the site is empty.
CI Usage
Once implement it could be used like this;
- uses: junobuild/juno-action@main
with:
args: hosting deploy --mode staging # commit only new/changed files
- uses: junobuild/juno-action@main
with:
args: hosting prune --mode staging # remove stale chunks, no downtime
Existing Building Blocks
The CLI already has everything needed:
- Local file scan + hash computation → used by deploy
- Live asset list fetch → used by deploy to skip unchanged files
- Single-file delete → exposed by juno hosting clear --fullPath
prune is composing these three existing things.
Questions
- Is the set-difference approach the right strategy, or is there a simpler internal hook I'm missing?
- Should deletions go through the change proposal system, or should prune be --immediate by default (since it's non-destructive to live content)?
- Is there a preferred place in the CLI source to add new hosting subcommands? Happy to follow existing patterns.
Overview
I'm volunteering to implement this if the approach looks right/there isn't already the functionality another way.
Let me know if you'd like any changes to the design, I will try and look to implement something over the coming weekend.
Feature
remove stale hosted assets without clearing the entire deployment
Problem
juno hosting deployis diff-based and only uploads changed files, this is great.But there's no way to remove files from a live satellite that are no longer in the current build output, without running
juno hosting clear(which wipes everything and re-certifies the full site).For large sites this is painful:
--clearre-commits all files in a single proposal, hitting the ICP 40B instruction limit on sites >~80 MBmain.abc123.js) are never overwritten, only orphaned.Proposed Solution
juno hosting pruneA new subcommand that removes files present on the satellite but absent from the current build output — without touching files still in use.
juno hosting prune [options]
Options:
--dry-run: Show what would be deleted without deleting--mode: Environment to target (production, staging, development)-h: --help Output usage informationAlgorithm
A work-in-progress, but I'm thinking something like this;
sourcedirectory (fromjuno.config) →local_fileslive_filesstale = live_files − local_filesstalevia change proposal (same mechanism as [deploy]I'm thinking it would be the inverse of the current deploy's skip logic
hash(local) == hash(live)prunedeletes:live_file ∉ local_filesZero Downtime
Only orphaned files are removed.
The satellite always serves a valid, complete set of assets. No window where the site is empty.
CI Usage
Once implement it could be used like this;
Existing Building Blocks
The CLI already has everything needed:
prune is composing these three existing things.
Questions