feat(projects): preserve managed volumes on project rename

[NeurekaSoftware]

Checklist

• This PR is not opened from my fork’s main branch

What This PR Implements

When an Arcane project is renamed, Arcane now keeps its automatically managed Compose volumes aligned with the new project name.

For example, renaming a project from nginx to web will move the data from nginx_data into the new web_data volume so the project continues using the same application data after the rename.

Volumes with an explicit fixed name: in the Compose file are left alone. External volumes are also left alone.

Fixes: #2898

Changes Made

• Added project-managed volume migration during project rename.
• Kept explicitly named and external Compose volumes unchanged.
• Added safety checks so volume migration only runs when the project is stopped and the source volume is not attached to containers.
• Added conflict handling for cases where the target volume already exists.
• Added rollback and recovery handling so failed or interrupted renames do not leave the project pointing at the wrong volume.
• Refreshed the project editor after failed saves so the UI returns to the current server state.

What Happens During A Rename

When a stopped project is renamed, Arcane checks the Compose volume definitions and finds volumes whose names were generated from the old project name.

For each matching managed volume, Arcane creates the new target volume, copies the data from the old volume into it, and then updates the project rename. After the project update succeeds, Arcane removes the old project-scoped volume.

If anything fails before the rename is completed, Arcane rolls the change back. It removes any newly created target volumes, restores the original project directory state when project files were edited, and keeps the project using the original volume names.

Arcane also writes a short rename journal while the rename is in progress. If Arcane restarts or is interrupted during the operation, startup recovery uses that journal to either finish cleanup after a completed rename or roll the rename back if the project update did not finish.

Testing Done

• Tested on a local build and everything worked great.

AI Tool Used (if applicable)

Codex / GPT 5.5 xhigh assisted with the implementation, design, and tests.

Additional Context

This change is intended to make project renames safer and less surprising. Without it, Docker Compose can create a new empty project-scoped volume after a rename, which can look like data loss even though the old volume still exists.

Disclaimer Greptiles Reviews use AI, make sure to check over its work.

To better help train Greptile on our codebase, if the comment is useful and valid Like the comment, if its not helpful or invalid Dislike

To have Greptile Re-Review the changes, mention greptileai.

Greptile Summary

This PR adds project-managed Compose volume migration during project rename: when a stopped project is renamed, Arcane creates new volumes with the updated name prefix, copies data from the old volumes, then removes the old volumes after the project record is committed. A KV-backed rename journal enables crash recovery and rollback, and the frontend refreshes project state after a failed save.

• project_volume_rename.go implements the full copy-rename-commit cycle using a busybox helper container, with pre-flight checks for target-volume conflicts and in-use sources.
• project_rename_journal.go persists rename progress and drives startup recovery, rolling back or completing partial renames automatically.
• project_service.go wires the new checks (ensureProjectStoppedForRenameInternal, live-status verification) and the backup/restore mechanism for compose-file edits that coincide with a rename.

Confidence Score: 5/5

Safe to merge; the core rename, recovery, and rollback paths are well-structured and covered by tests.

No logic defects in the rename or recovery flow were found. The backup-and-restore path correctly tracks the physical directory location across withProjectRenameRollback, journal recovery handles the directory and volume states consistently, and the DB transaction boundaries around Commit() are sound. The two findings are style and SQL-wildcard correctness nits with no impact on the happy path.

No files require special attention beyond the two inline suggestions.

_{Reviews (3): Last reviewed commit: "fix(projects): recover missing rename ta..." | Re-trigger Greptile}

Context used:

• Rule used - What: All unexported functions must have the "Inte... (source)

[NeurekaSoftware]

@greptileai

[NeurekaSoftware]

@greptileai

[kmendell]

Ill have to look into this more, but doesnt just recreating the project do this?

Alos note: the name field in arcane ui is pretty much just the name for the folder and for internal refernce of it it doesnt get passed to docker (i dont think :O) anymore or at least it shouldnt

[NeurekaSoftware]

Ill have to look into this more, but doesnt just recreating the project do this?

Just an example, my "media-server" stack has 13 volumes.

Renaming the project / renaming the folder is the same as changing the stack name.

Managed volumes are named {stack}_{volume}

So renaming my "media-server" stack to "media-services" will result in brand new volumes being created when I bring it up again, unless I manually rename all previous volumes.

The exception to the stack name changing when the folder name changes is when you have a name: mystack at the top of your compose file- but if I remember correctly Arcane wasn't actually respecting that value for some reason? I would have to double check.

[NeurekaSoftware]

I just confirmed, having the stack name in the compose file should make the volumes stable but arcane doesn't respect that value for some reason.

When using docker via the CLI, you can have a name: stackname value in the compose file and you can rename the parent directory and volume names are stable. But if the name isn't in the compose file the stack name will change if the parent folder name changes.

This is why this change is needed. It adds complexity to renaming projects but it ensures nothing ever breaks when managing projects via arcane.

[NeurekaSoftware]

Reproduction Steps

Scenario 1: No name: Defined (Current Problem)

Create a Compose project:

services:

  nginx:

    image: nginx:alpine

    volumes:

      - data:/data

volumes:

  data:

Place it in a folder named:

media-server/

Bring the stack up:

docker compose up -d

Docker creates:

media-server_data

Rename the folder (or rename the stack in Arcane):

media-server/

↓

media-services/

Bring the stack up again:

docker compose up -d

Docker now creates:

media-services_data

Result:

• A brand new volume is created.

• Existing data remains in media-server_data.

• Containers start with an empty volume.

• User must manually rename or migrate volumes.

---

Scenario 2: name: Defined (Docker CLI Behavior)

Create a Compose project:

name: media-server

services:

  nginx:

    image: nginx:alpine

    volumes:

      - data:/data

volumes:

  data:

Place it in a folder named:

media-server/

Bring the stack up:

docker compose up -d

Docker creates:

media-server_data

Rename the folder:

media-server/

↓

media-services/

Bring the stack up again:

docker compose up -d

Docker still uses:

media-server_data

Result:

• No new volumes are created.

• Existing data is reused.

• Folder renames do not affect volume names.

• Stack resources remain stable.

[NeurekaSoftware]

Arcane doesn't seem to respect scenario 2 either, which probably needs its own separate bug report.

Once the bug with arcane not respecting scenario 2 is fixed, this PR should be modified to exclude migrating volumes when a project is renamed if name: mystack is both present in the compose file AND hasn't changed value.

[github-actions]

This pull request has merge conflicts. Please resolve the conflicts so the PR can stay up-to-date and reviewed.