Updates
How your app gets Stardeck's new Modules, fixes and features, what an update does to each Module, and how to stop updates.
Every app starts from the same foundation: the Modules, the admin, the sample data and the code around them. The app is yours from the first commit, and Stardeck keeps improving that foundation. When it releases a new version, your app shows Update available, with what changed and whether the change is major, minor or a patch. Every Module comes along: fixes, new features, new tests.
Taking an update merges Stardeck's changes into your app's code. Your own files stay yours: the code you wrote, your theme, your word and sample-data changes, and the screens you customized.
Take an update in the product
Open Update available in the project toolbar to read the changes, then let your app's agent
merge them in the chat. Use this when your app is lightly customized. Stardeck records the update
once the merge reaches main.
Take an update locally
If your app is heavily customized, review every changed line in your own checkout before anything lands. Your agent runs the git steps for you.
Take an update locally
Merge a Stardeck update from your local workspace through a pull request
What happens to each Module
| Your Module is | The update |
|---|---|
| Untouched | Replaces it with the new version |
| Switched off in the Modules tab | Updates it all the same, so it's current when you switch it on |
| Customized screens | Updates the core and merges into your screens (see Customize a Module's screens) |
| Detached | Leaves it alone |
| Uninstalled | Keeps it out |
| New in this version | Adds it switched off, until you switch it on |
Your own files are never overwritten: the extensions file, the admin overrides, the theme, your string overrides and your customized sample data are all the app's.
What to check afterwards
- Customized screens: the update lists the customized files it also changed and the hooks it added or removed. Wire new hooks in; don't reimplement them.
- String overrides: check each overridden key against the Module's new English text, and reword yours where the meaning changed. An override of a key the update removed fails the build and names it. See Customize a Module's words.
- Customized sample data: run the reset test. It fails on a customized table that gained a required column. See Customize sample data.
- Admin overrides and slot entries: a renamed page, area or slot is reported by name, rather than quietly bringing a hidden page back or dropping your section.
- Schema: a Module's table changes arrive as entries in Stardeck's schema ledger, applied to each environment's database in order. A production schema change needs its own approval.
- Breaking changes: a release that removes or renames something your code uses is a major version, and its changelog carries instructions your agent follows to move your code over.
Then run the app's checks and tests, deploy a preview, and look at it before production. See Publishing & Deployment.
Stop updates
You can stop updates for one Module or for the whole app, in Settings → Modules:
- For one Module, open its actions menu and choose Stop updates for this Module. The whole Module becomes yours to edit.
- For the whole app, open the tab's menu, choose Stop all Stardeck updates, and confirm with Stop all updates. Every Module becomes yours, and the app stays on the version it has.
Both are permanent. Other Modules that use a Module you stopped keep updating, so they can break against your copy; the warning lists them. To change only how a Module's pages look, customize its screens instead, which keeps its logic on updates. See Customize a Module's screens.