Hey folks, hoping to tap into the collective wisdom here. We've been using Runway for about 18 months now, and it's been fantastic for managing our project environments. But we're starting to get a bit of a sprawl situation—dozens of old, inactive projects cluttering the main view. I don't want to just delete them, as we might need to reference the configs or logs someday for audits or to revive a feature. 😅
Has anyone built a solid workflow for archiving projects? I'm thinking along the lines of:
* **Snapshotting the final state** (services, env vars, maybe even a specific deployment hash).
* **Moving it out of the active dashboard** without a full delete.
* **Keeping some metadata searchable** so we can find it later.
I know Runway has the "Delete Project" option, but that feels too permanent. I've considered just using a naming convention like `z-archive-project-name`, but that's a bit clunky. I also thought about using the API to dump the project configs and store them in a git repo tied to our internal docs, but that's extra overhead.
Anybody solved this in a cleaner way? Maybe a script that uses the GraphQL API to fetch and store the project's `.runway.yaml` and key details? Would love to see some examples if you've got them.
-jk
> I know Runway has the "Delete Project" option, but that feels too permanent.
Good. It should feel permanent. Deleting something is deleting it.
Your naming convention idea is clunky, but it's the least bad option. Create an `archive/` folder via the API, move them there. Script it once. The API dump-to-git idea is just creating a different pile of stale configs you'll never look at.
The real problem is thinking you need every byte of state. You don't. Keep the final `.runway.yaml` in your actual project's git repo. That's the only artifact that matters. The logs and deployment hashes in the platform are just expensive breadcrumbs.
-- old school
Hey user561, totally get the sprawl problem. That naming convention trick with `z-archive-` is something I've seen a few teams do, and honestly, it's a decent stopgap if you just need to clear the dashboard view fast.
But you're right, it's clunky. The API-to-git idea has merit for searchability, but I'd simplify it: don't try to dump *everything*. Just script a final pull of the project's `.runway.yaml` and the last successful deployment hash, then tag it in your main project repo. That way, the audit trail lives where the code already does. Runway's logs are ephemeral, but a tagged commit with the final config is a solid reference point if you ever need to revive something.
Ship fast, measure faster.
I agree that the `z-archive-` prefix is a clunky stopgap, and I've found it breaks down quickly once you have multiple people managing the dashboard. The API-to-git approach you're considering is closer to a sustainable solution, but you're right to be wary of the overhead.
The key is treating the platform project as a transient execution record, not the source of truth. My team scripted a process that triggers on project deactivation. It pulls the final `.runway.yaml`, the last deployment's hash, and a JSON dump of the environment variables (sanitized, of course) and creates a tagged commit in the associated application repository. We use a consistent tag format like `infra/runway-archive--`. This keeps the audit trail coupled with the codebase it actually deployed.
For searchability, we maintain a simple markdown file in our internal docs that acts as an index, linking the project name to that git tag and noting the business reason for archiving. It's minimal maintenance, but it means you don't have to dig through git history blind. The actual Runway project gets deleted after the archive commit is verified, which fully clears the dashboard clutter. The logs are indeed ephemeral, so we accept that loss, but the config and deployment hash are what you truly need for a revival.
Data > opinions