Everything Startup OS knows about how to operate your product lives in one repository: the Operations Instance in your own GitHub organization. Not in our database. The dashboard reads it, shows it in plain language, and can propose changes to it. It cannot change it.
Open a product in the dashboard and choose Configuration to see its settings.
Current, pending, and running
The page shows each setting three ways, and the difference between them matters more than anything else on it.
| Word | Means |
|---|---|
| Current | What is merged on your repository’s main branch. This is what your product is configured with. |
| Pending | What an open pull request proposes. Not in effect. A proposed value sits in a pull request until you merge it, and the page never shows it as the value. |
| Running | What your product’s scheduled turns report they actually read. |
Finding what needs a look
Needs a look counts three kinds of value. A placeholder is text the template shipped for you to
replace, such as replace.me; it is live configuration until you do. A setting that is not set has
no value at all. A starting value is what the template proposed rather than an answer you gave.
Each section’s heading repeats its own counts.
Above the sections, Find a setting filters every section by name, description, or value, and Needs a look or Starting values shows only those. Permissions are drawn as one ladder, from Allowed to Denied, so you can read down a column to see everything at one level. The schedule is one row per turn. Edit opens the section’s settings in a panel beside the page.
Merging is not the same as running
Your product runs on a schedule: a set of recurring turns, each starting at its own time. Every turn reads your configuration when it starts. So after you merge a change, the turns pick it up one at a time, as each next runs, not all at once at the moment of the merge.
That is why the page lists what each turn is running, and marks the ones that have not yet picked up your change as behind. Behind is normal. It is not a fault, and nothing is broken.
A turn that has never reported reads as Not yet reported. That means exactly what it says: no turn has told us which configuration it read. It does not mean everything is fine, and it does not mean anything is wrong.
Why every change is a pull request
When you change something here, Startup OS opens a pull request in your repository and stops. You merge it. Nothing Startup OS runs can merge it for you, and that is deliberate.
Some of these settings decide what Startup OS may do without asking you: publish content, email customers, deploy, spend money. A system that could grant itself those permissions would not be one you could meaningfully supervise. The merge is where you say yes.
So the button says Create update PR, never “Save”. If it said Save you would believe the change had taken effect, and it would not have.
What changing a permission does
Many of these settings are permissions: whether Startup OS may open issues, publish content, post to social channels, change pricing, and so on. Each is set to one of five values, explained in Permissions and operating modes.
Your product’s operating mode is not a setting you pick. It is worked out from these permissions, so changing a permission can change your mode. The review screen tells you which one in words before you propose anything, for example:
This moves the product from Prepare to Operate. Startup OS will be permitted to post to social channels without asking first. That reaches people outside your team, on a schedule, with nobody in between.
You tick to say you have read it. That sentence appears again in the pull request, so whoever merges it reads the same words you agreed to.
What you cannot change here
Some settings are read-only, and each says why on the page rather than just refusing.
- Identifiers. Your product’s id is the name of every folder its run history lives in. Renaming it would orphan all of it, so that is a migration rather than a setting.
- Which repositories belong to the product. That list is what Startup OS checks before acting on anything. Adding to it widens what it may touch, so it stays a deliberate repository change.
- Credentials. The page shows whether a source is connected and which provider it is. It never shows a key, and you can never enter one here. Credentials are set with
startup-os connectand in your repository’s own secrets.
If something goes wrong
| Message | What happened | What to do |
|---|---|---|
| “Your values are still here” | Someone changed the configuration while you were editing. Nothing was written, and what you typed is still in the form. | Open the page again in another tab to see what moved. |
| “Edited outside the dashboard” | Someone edited the pull request in GitHub. Startup OS will not push over their work. | Review or close that pull request, then come back. |
| “Carries notes that rewriting it would delete” | The list you are editing has comments beside its entries in the file, and rewriting it would delete them. | Edit that one in the repository. |
| “This product’s manifest could not be read” | The configuration file on your main branch is not valid. No values are shown, because a plausible-looking blank would be worse than nothing. | Fix the file and the page returns. |
Undoing a change
Before you merge, close the pull request. Nothing changes.
After you merge, revert the merge commit in GitHub, or come back and change the value again. Both are ordinary repository operations, because the configuration is an ordinary file in your own repository.
Strategy and experiment state
The configuration editor does not accept a GTM thesis or register an experiment. Those are retained business records with exact decision bindings, reviewed through the complete proposal path. Settings still control actions, schedules and execution ownership. Updating business strategy does not open a permission or change a schedule. See Go-to-market workflow.