OneEnv
← All posts🐙 Part 21 of 21

Bring Your Repos In, Find Anything Once They're There

ShareLinkedInX

Everything we'd shipped so far assumed you'd already gotten your services and env keys into OneEnv — by hand, one Service and one Env Master at a time. That's fine for a handful of repos; it's real friction for a team migrating twenty. And the more a workspace grows across four governed domains, the harder it gets to just find the one thing you're looking for. Two additions this cycle, neither touching the governance model itself, both aimed at that friction.

Import straight from GitHub

An Owner/Admin connects a workspace to GitHub once (a personal access token, verified and stored — never echoed back in any response), then browses that account's repos and branches from inside OneEnv. Select the ones you want and OneEnv creates a real Service per repo, same as if you'd typed it in by hand.

Connect GitHub
Owner/Admin, once per workspace
→
Pick repos + branches
→
Import run queued
processed in the daily window
→
Real Services created
env keys pre-populated

Import isn't instant by default — runs are queued for a daily processing window rather than competing for compute the moment they're submitted. The result is the same either way: the same Services, the same pre-populated Env Masters, the same governance rules apply to them from the moment they exist. Import is a faster on-ramp, not a side door around review.

Find anything in one search

A workspace with real usage spans four governed domains plus services — by the time you're looking for "that one column on the billing table" or "the route that returns user profiles," clicking through tabs is slower than just knowing. Ctrl+K opens a single search across all of it at once.

Services
by name
Env values
by key
DB masters, tables & columns
by name / key
API routes
by name
Validation rules
by name

It's not a shortcut around anything else the app already enforces. Results are filtered through the same per-service visibility a member already has everywhere else — a service you can't see doesn't surface here either, it isn't just hidden client-side. And a row that's still a private, unmerged draft — a proposed column or route waiting on its own branch — is excluded entirely, the same convention the API health report already follows, rather than showing up as a confusing result you can't actually act on yet.

ShareLinkedInX