SiliconForge

Documentation for SiliconForge 0.1.2.

Home / Docs / Update, back up and uninstall

Update, back up and uninstall

Applies to SiliconForge 0.1.2 · Updated . Check platform limits.

Before this task: Understand platform and artifact verification →

Keep the application, project files, project history and credentials separate. Replacing one does not automatically back up or restore the others.

Before an update or migration

Record the current application release and platform, installation location, project roots and tool configuration. Save native-source edits and finish or cancel active jobs deliberately. Close the application before taking a filesystem backup of project databases; copying an actively changing SQLite directory is not a reliable backup.

Back up a complete working project

  1. Preserve native RTL, testbenches, constraints, build descriptions, dependency locks and license material.
  2. If you need Git history, preserve .git as well as the worktree. A committed-tree export is not a backup of all branches, uncommitted work or untracked files.
  3. If you need SiliconForge's local operational history, preserve the closed project's .siliconforge directory as part of the private backup. It contains local state including the index and candidate/evidence material; a clean source export deliberately has a different scope.
  4. Store the backup privately and test restoration into a different directory. Inspect source and history before relying on it.
  5. Handle credentials through their authorized credential-store backup/recovery mechanism. Never copy keys into a project merely to make the backup “complete.”

Expected result: a restorable private project backup with its intended history, not just an archive that happens to exist. Sharing a project export and keeping a private backup are different tasks.

Install and test a replacement runtime

  1. Read the release notes and platform release metadata. Verify the new download's hash and signature.
  2. Preserve the prior verified installation. Install the new release using its normal platform mechanism; never overlay files onto a running extracted runtime.
  3. Open a disposable copy of a representative project first. Check source access, Design indexing, Changes history and required tool checks.
  4. Refresh the desktop subscription online and confirm its paid-through date; existing paid installations do not need to repurchase. Check the AI route and tool doctor status without sending an unnecessary request. An application update is not a tool-pack upgrade.
  5. Only then resume active work. Keep the prior version and backup until the new workflow is established.

For example, use the stream register to confirm the new runtime opens native source and indexes the design. Run its deterministic test with the same simulator; distinguish that external tool result from a new application verification receipt.

Rollback boundaries

Use the supported compatible rollback route described on release recovery. Do not assume an older application can read state already updated by a newer version. Restore a compatible copy for testing rather than pointing an old binary at your only working project. Application rollback does not revert applied RTL edits, Git commits, dependency changes or subscription state.

The source runtime CLI has managed-generation install/update/rollback operations; those are not universal replacements for the Windows installer or an arbitrary AppImage. Use only the lifecycle matching how that runtime was installed.

Remove the application, not your work

On Windows, use the installed application's normal uninstaller through Windows installed-app management. On Linux, remove an extracted bundle or AppImage only after closing it and confirming it contains no project data; remove any launcher/menu registration that points to that retired location. Managed-generation installations should use their matching managed uninstaller instead of hand-editing generation records.

Retain projects and backups unless you explicitly intend to delete them. Uninstalling does not cancel a paid subscription, erase provider-side data or revoke an external API key. Use billing management and the relevant credential/provider controls separately.

If the update cannot be validated

Preserve the new error, old runtime and untouched backup. Record whether the failure concerns startup, project schema/indexing, tools or authentication. Do not delete .siliconforge, reset Git or wipe credentials as a first response. Use layered diagnosis and resume from a compatible copy only after checking it.

Related: verified installation, shareable packages, project changes.

Update notices

Starting with version 0.1.1, open About SiliconForge / updates for a manual check, platform-specific download, or the automatic-check preference. Automatic checks run in the background at most once per day, including after a failed attempt. You can disable them in About, or choose Don’t notify me about this version without hiding newer releases. Manual checks remain available. An available update includes its numbered release notes and the download for this computer. Checks do not install anything, alter projects or activate a subscription. A network failure does not prevent local work. Subscribe to the release feed for notices without email signup.

Need help? Report an issue. Include your application version; never include credentials.