Decommission an Old Feluda Computer

Decommission an Old Feluda Computer

Decommissioning an old Feluda computer means removing its ability to run workflows, access connected services, store protected data, or create new activity.

This process normally begins only after a replacement computer or another approved environment has been tested successfully.

A complete decommission should address:

• Feluda user data;
• Studio workflows;
• Journal entries;
• RunFlows history;
• scheduled workflows;
• local AI models;
• local MCP servers;
• source and output files;
• local databases;
• protected credentials;
• network and account access;
• backups; and
• final device cleanup.

Do not begin by uninstalling Feluda.

First confirm that important data and workflows have been preserved.

When to decommission a computer

Decommissioning may be required when:

• a replacement computer is ready;
• the device is being returned;
• the device is being sold or recycled;
• the user is leaving the organisation;
• the operating system is no longer supported;
• the hardware is unreliable;
• the computer is no longer approved;
• the local environment has moved elsewhere; or
• the device should no longer access Feluda services.

The final cleanup method should match the reason and your organisation's device-handling requirements.

Define completion before you start

The old computer should be considered decommissioned only when:

• important data has been backed up;
• required workflows work in the replacement environment;
• all schedules on the old computer are stopped;
• active tool calls have ended;
• connected accounts are reviewed;
• old-device credentials are revoked or removed;
• local MCP services are stopped;
• local databases and files are preserved or removed;
• Feluda user data is handled correctly;
• the application is uninstalled when appropriate;
• external services show no new activity from the device; and
• final verification has been recorded.

Assign a decommission owner

One person or team should coordinate the process.

The owner should know:

• why the device is being retired;
• where the replacement environment runs;
• which Feluda workflows lived on the device;
• which credentials were stored there;
• which local services were installed;
• what data must be retained;
• what data must be removed;
• who approves final cleanup; and
• how the device will be handled afterward.

Confirm the replacement environment

Before changing the old computer, confirm that the replacement environment can:

• open Feluda;
• load Studio workflows;
• display required Journal entries;
• use the intended AI provider;
• run the required local model;
• connect to the required MCP server;
• access approved sources;
• write to approved destinations;
• complete RunFlows tests;
• complete one-time scheduled tests; and
• operate offline when required.

Keep the old computer unchanged until these checks pass.

Create a final inventory

Record what the old computer contains.

Include:

• Feluda version;
• Feluda user-data location;
• Studio workflows;
• Journal content;
• Genes;
• provider configuration;
• local model runner;
• downloaded models;
• MCP server connections;
• local MCP services;
• source folders;
• output folders;
• local databases;
• schedules;
• credentials;
• network rules;
• backups; and
• external destinations.

Do not record raw secret values.

Pause all schedules

Open Schedule Manager and pause every schedule on the old computer.

Confirm:

• no upcoming run remains active;
• no recurring flow will restart;
• no one-time run is still pending;
• no overlapping run is in progress;
• no production write is expected; and
• the replacement schedule has been tested separately.

Record the schedules that were paused or removed.

Check active RunFlows work

Review active and recent RunFlows executions.

Confirm that:

• no important run is still active;
• no tool call is waiting;
• no write action is incomplete;
• no delayed result is expected;
• no failed confirmation hides a completed write; and
• no duplicate action will occur during cutover.

Inspect external destinations before repeating or cancelling uncertain writes.

Review Workbench Activity

Check recent Workbench Activity for:

• MCP tool calls;
• file writes;
• database changes;
• messages;
• Journal writes;
• repeated calls;
• errors; and
• incomplete actions.

This helps identify activity that may need final verification.

Take a final backup

Create or confirm a current backup of required information.

The backup may include:

• Feluda user data;
• Studio workflows;
• Journal entries;
• important source files;
• required output;
• local databases;
• MCP configuration records;
• model and runner details;
• schedule records;
• permission records; and
• recovery notes.

Store the backup in an approved location.

Verify the final backup

Confirm that:

• the backup exists;
• the date is correct;
• expected folders are present;
• expected files are present;
• database exports completed;
• encryption works when required;
• the backup is readable; and
• a restoration test has succeeded when possible.

Do not erase the old computer before the backup is verified.

Review Feluda user data

Feluda stores user-created content separately from the application itself.

On Windows, this is normally under:

%APPDATA%\Feluda\

On Linux, it is normally under:

~/.config/Feluda/

Or:

$XDG_CONFIG_HOME/Feluda/

On macOS, confirm the active Feluda application-data location using the current installation guidance and the operating system's application-data tools.

Decide whether the user-data folder should be:

• backed up and removed;
• transferred and then removed;
• retained temporarily for an approved rollback period; or
• preserved according to policy.

Review Journal content

Journal entries may contain:

• reports;
• research notes;
• workflow results;
• personal information;
• internal records; or
• user-written notes.

Preserve required entries before removing local data.

Do not keep unnecessary sensitive Journal content on a retired device.

Review local source files

Identify local files used by MCP tools or workflows.

Confirm whether each source should be:

• transferred;
• archived;
• backed up;
• retained on another approved system; or
• securely removed.

Check:

• project folders;
• document collections;
• downloaded datasets;
• temporary source files;
• synchronised folders; and
• duplicate local copies.

Review local output files

Generated output may include:

• reports;
• exports;
• generated documents;
• local summaries;
• test files;
• logs; or
• temporary workflow results.

Preserve only what remains useful or required.

Remove test and temporary output that has no continuing purpose.

Review local databases

A local database may hold information that is not stored anywhere else.

Before removal:

• identify every dependent workflow;
• stop all writes;
• create a valid database backup;
• test restoration;
• export required records;
• confirm the replacement database works;
• stop the database service; and
• obtain final approval.

Do not delete database files while the service is active.

Review downloaded AI models

Local models can use significant storage.

Decide whether model files should be:

• copied to the replacement computer;
• retained in the final backup;
• downloaded again later; or
• removed from the old device.

Record the exact model and version when reproducibility matters.

Model files normally do not contain workflow content, but they may still be subject to your organisation's software-handling rules.

Stop the local model runner

Stop local AI services such as:

• Ollama;
• LM Studio server; or
• another local model endpoint.

Disable automatic startup when the service is no longer needed.

Confirm that the old computer can no longer provide model access to another device on the network.

Stop local MCP servers

Identify every local MCP server running on the computer.

For each one:

• stop active processes;
• disable automatic startup;
• remove scheduled startup tasks;
• confirm the listening port is closed;
• preserve required configuration records;
• archive required logs; and
• remove the service when appropriate.

Confirm that no other approved workflow still depends on the old local endpoint.

Review MCP connections

Open MCP Servers in Feluda.

Record and then remove or disable connections that should not remain on the old device.

Confirm:

• which accounts they use;
• which tools they provide;
• whether they are local or remote;
• which permissions they require; and
• whether the replacement environment has been tested.

Removing a connection from Feluda does not necessarily revoke external access.

Review AI provider access

Open AI Providers.

Identify:

• cloud provider credentials;
• local provider endpoints;
• unused providers;
• test providers;
• production providers; and
• duplicate provider records.

Remove provider access that should not remain on the old computer.

Revoke or rotate credentials

Credentials may include:

• API keys;
• access tokens;
• passwords;
• database credentials;
• protected headers;
• service-account access; or
• VPN credentials.

Revoke or rotate credentials when:

• they were created for the old device;
• the device is leaving your control;
• the owner changed;
• the replacement uses a new credential;
• exposure is possible; or
• continued access is unnecessary.

Perform revocation through the connected service.

Remove protected secrets

Feluda stores supported secrets through the operating system's secure credential store.

Depending on the operating system, this may use:

• Windows Credential Manager;
• macOS Keychain; or
• a Linux keyring.

Remove old-device secrets through the approved operating-system process.

Do not export them into plain text before removal.

Verify revocation

Confirm that:

• old credentials no longer authenticate;
• old service accounts are disabled when appropriate;
• old VPN access is removed;
• no server still uses the old value;
• no schedule depends on it;
• external activity has stopped; and
• the replacement credential works where required.

Remove account access

Review accounts that may remain active on the old computer.

These may include:

• operating-system accounts;
• cloud provider accounts;
• database accounts;
• business application accounts;
• local service accounts;
• VPN accounts; or
• shared team accounts.

Sign out, remove, disable, or revoke them according to the approved process.

Remove network access

Review:

• VPN profiles;
• proxy settings;
• firewall rules;
• open ports;
• local-network shares;
• saved wireless networks;
• remote desktop access;
• SSH access; and
• internal certificates.

Remove access that the retired device no longer needs.

Review local permissions

Remove unnecessary:

• administrator rights;
• broad folder permissions;
• database permissions;
• network share access;
• service startup rights;
• write access; and
• local user access.

Keep only what is needed during the approved rollback period.

Remove old schedules outside Feluda

The computer may have automation outside Schedule Manager.

Check for:

• operating-system scheduled tasks;
• login startup items;
• local scripts;
• database jobs;
• service timers;
• shell jobs;
• background applications; and
• external automation that targets the device.

Disable or migrate them before cleanup.

Unlink the device when applicable

When the Feluda installation is linked to an account or device-management process, remove or unlink the old device through the available account or application controls.

Confirm that the replacement device remains active.

Do not leave an unused device authorised without a clear reason.

Uninstall Feluda

Uninstall Feluda only after:

• backups are verified;
• replacement workflows work;
• schedules are stopped;
• credentials are revoked or removed;
• local services are stopped;
• required data is preserved; and
• final approval is given.

Uninstalling the application may not remove every user-data file or credential.

Review those locations separately.

Remove local model software

When the device no longer needs local AI, remove:

• local model runners;
• downloaded model files;
• automatic startup settings;
• local server configuration; and
• related caches

according to the approved software-removal process.

Confirm that no other local user depends on them.

Remove MCP server software

Remove local MCP server packages, configuration, caches, and logs only after:

• dependencies are cleared;
• required records are preserved;
• replacement services are verified;
• credentials are revoked; and
• the service is stopped.

Do not remove shared source data accidentally.

Remove sensitive local data

Sensitive local data may include:

• Feluda user data;
• Journal entries;
• source files;
• output files;
• database files;
• temporary files;
• caches;
• logs;
• exported records; and
• backup copies.

Use the secure removal method required by your organisation and the device's final destination.

Review synchronised folders

A synchronised folder may remove data from more than one device if files are deleted carelessly.

Before cleanup, confirm whether the folder is:

• local only;
• synchronised;
• shared;
• backed up elsewhere; or
• controlled by another service.

Remove only the local copy when that is the intended action.

Review browser and application data

The old computer may also store:

• downloaded reports;
• login sessions;
• cookies;
• browser history;
• copied prompts;
• screenshots;
• exported files;
• support attachments; or
• clipboard history.

Include these in the device-cleanup review when they contain Feluda-related information.

Review logs and temporary files

Local applications may create:

• model logs;
• MCP logs;
• database logs;
• workflow logs;
• temporary documents;
• cached results;
• crash reports; or
• diagnostic files.

Preserve only what is required for support, audit, or incident review.

Confirm no external activity remains

After access is removed, review external services.

Confirm that:

• no new tool calls originate from the old device;
• no new records are created;
• no messages are sent;
• no files are uploaded;
• no database changes occur;
• no old account signs in;
• no local server remains reachable; and
• no schedule continues to run.

Verify the replacement one final time

Before final device erasure or handover, run the replacement environment's known-good tests again.

Confirm:

• Workbench works;
• Activity shows the intended tool;
• Studio workflows load;
• RunFlows completes;
• write destinations are correct;
• no-result and error paths work;
• one-time scheduling works;
• recurring schedules are stable; and
• no dependency still points to the old computer.

End the rollback period

Keep the old device available only for the agreed rollback period.

End the rollback period when:

• all important workflows are stable;
• scheduled runs have completed successfully;
• users have adopted the new environment;
• no missing data has been reported;
• no old-device dependency remains;
• backups are verified; and
• final cleanup is approved.

Apply the final device-cleanup process

The final step depends on what will happen to the device.

Possible processes include:

• organisational reimaging;
• secure erase;
• operating-system reset;
• managed device return;
• approved recycling;
• internal reassignment; or
• storage destruction.

Follow the process required by the device owner.

Record the decommission

Record:

• device name;
• device owner;
• decommission reason;
• decommission date;
• replacement environment;
• backup location;
• workflows moved;
• schedules removed;
• credentials revoked;
• accounts disabled;
• local services stopped;
• data removed;
• software removed;
• final external-activity check;
• reviewer; and
• final approval.

Do not include raw credentials.

Monitor after decommissioning

During the first normal work period, watch for:

• missing workflows;
• failed schedules;
• users trying to reach old tools;
• old account activity;
• unexpected local-server traffic;
• duplicate writes;
• missing files; or
• requests for data that was removed.

Address missed dependencies without restoring unnecessary old access.

A practical decommission routine

Use this process:

1. Confirm the replacement environment.
2. Assign a decommission owner.
3. Inventory Feluda data, models, MCP services, files, databases, and access.
4. Pause all schedules.
5. Review active RunFlows and Workbench Activity.
6. Take and verify a final backup.
7. Preserve required Journal, source, output, and database content.
8. Stop the local model runner.
9. Stop local MCP servers.
10. Remove MCP and provider connections.
11. Revoke or rotate credentials.
12. Remove protected secrets from the operating system.
13. Remove account, VPN, network, and local permissions.
14. Disable automation outside Feluda.
15. Unlink the old device when applicable.
16. Uninstall Feluda and local services when appropriate.
17. Remove sensitive local data.
18. Verify that no external activity remains.
19. Recheck the replacement environment.
20. End the rollback period.
21. Apply the approved final device-cleanup process.
22. Record and approve completion.

Final decommission checklist

Before declaring the device decommissioned, confirm that:

• the replacement environment is stable;
• the final backup is verified;
• required user data is preserved;
• all schedules are stopped;
• no active tool calls remain;
• local model services are stopped;
• local MCP services are stopped;
• required databases are backed up;
• MCP connections are removed;
• provider access is removed;
• credentials are revoked or rotated;
• protected secrets are removed;
• local and network access is removed;
• automation outside Feluda is disabled;
• sensitive local data is removed;
• Feluda and related software are removed when appropriate;
• external services show no new activity;
• the rollback period is closed; and
• final cleanup and approval are recorded.

An old Feluda computer is fully decommissioned only when it can no longer access protected services, run automation, or retain unapproved local data.