Renaming a GitHub Repository Behind an App Store Application

Pennsieve identifies an App Store application by its repository URL. When you rename a repository on GitHub, Pennsieve does not carry the App Store application over to the new name — the renamed repository is treated as a new application. The original application, and any workflows using it, keep working unchanged.

This is by design: renames are managed by you, the app owner. This guide describes what happens after a rename and the steps to move over.

What happens when you rename a repository

Say you rename my-org/old-app to my-org/new-app on GitHub:

	Behavior
My Code	The repository appears under its new name (`new-app`). Use the refresh icon if it doesn't show up immediately.
Old App Store application	Remains in the App Store under the old name, unaffected. All existing versions stay deployed and runnable.
Existing workflows	Workflows referencing the old application continue to run successfully. Nothing breaks.
New App Store application	Nothing appears until you publish a release from the renamed repository. The first release registers a separate application under the new name.

The old and new applications are independent: they have separate version histories, separate permissions, and separate entries in the App Store catalog.

Steps to complete a rename

Rename the repository on GitHub (Settings → General → Repository name).
Confirm Pennsieve sees it — open My Workspace → My Code and check the repo is listed under its new name. If not, click the refresh icon, or use Update Integration on the GitHub card to confirm the Pennsieve GitHub Application still has access.
Check publishing settings — open the repo's Publishing Settings and confirm App Store is still enabled for the renamed repo.
Cut a release from the renamed repository (a new tag, e.g. v1.0.0). This registers the application in the App Store under the new name and builds it as usual.
Update your workflows — the new application is not swapped into existing workflows automatically. Add it to workflows yourself:
- For new workflows, select the new application from the App Store.
- For existing workflows you want to migrate, replace the old processor node with the new application and re-apply any parameter values.
Retire the old application when ready — once no workflows depend on it, the owner can remove the old application from the App Store. If other users or teams rely on it, coordinate before removing; existing workflows using the old app keep running as long as it remains in the App Store.

Things to keep in mind

Version history does not transfer. The new application starts fresh at its first release. The old application keeps the historical versions.
Permissions do not transfer. If the old application was shared with users, teams, or workspaces, re-apply that sharing on the new application.
Nothing is deleted automatically. Pennsieve never removes the old application on a rename — cleanup is entirely in your hands.
Both can coexist indefinitely. If you want a transition period, leave both applications in place; old and new workflows run side by side.