Rubick Backup
You run a rubick backup by exporting your local app state to a file or cloud store. This saves your installed plugins, custom shortcuts, and user settings for quick recovery. Developer teams use this desktop launcher to speed up daily tasks. Engineers build custom workflows and store API tokens inside their local tools. Teams often share backup files or sync folders across multiple work laptops. When storage roles are too broad, anyone on the team can read those synced files. One shared backup
Backup Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run a rubick backup by exporting your local app state to a file or cloud store. This saves your installed plugins, custom shortcuts, and user settings for quick recovery.
Developer teams use this desktop launcher to speed up daily tasks. Engineers build custom workflows and store API tokens inside their local tools. Teams often share backup files or sync folders across multiple work laptops. When storage roles are too broad, anyone on the team can read those synced files. One shared backup archive can expose private keys and production database credentials to the whole group.
How a native rubick backup works
The launcher keeps its core state in a local data folder on your machine. This folder holds plugin lists, global hotkeys, and local storage files for each extension. You can make a manual copy of this data folder at any time. Many users also set up cloud sync through built-in account settings or third-party drives. When you set up a new computer, you import the saved archive into the fresh app. The tool reads the file, downloads your plugin list, and puts your shortcuts back in place. This process moves both basic preferences and local plugin databases from one machine to another.
What native sync solves and what it leaves open
Built-in sync and local file exports solve the problem of lost productivity. If a laptop breaks, an engineer can restore their workspace in a few minutes. They do not need to rebuild custom scripts or hunt down old plugins by hand. Still, native file exports create a big security gap for engineering teams. The backup system only checks who can read or write the storage bucket. It does not check what lives inside the backed-up plugin data. Developers often paste live database passwords or cloud keys into productivity extensions for fast testing. When the app packs those settings into a backup file, those secrets travel in plain text. If an attacker steals the backup archive, they get full entry into your live systems. Also, once a developer restores a shared profile, the static keys work right away. The native setup decides who downloads the backup file. It cannot inspect or control the live commands and database queries that those restored tools run.
Best practices for safe workspace backups
Teams should separate visual preferences from secret keys before they run a backup. You should store hotkey maps and public plugin lists in standard shared folders. Never save live database credentials or production tokens inside local launcher plugins. Instead, engineers should fetch temporary credentials only when a task needs to run. You should also audit shared cloud folders to make sure old backups do not hold sensitive data. If a backup contains customer test data, masking rewrites matched fields like emails and phone numbers in results. Keeping secrets out of local app storage makes workspace recovery safe and clean for everyone.
Backup Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What data gets saved in a standard rubick backup?
A standard backup saves your global app preferences, custom hotkeys, and installed plugin lists. If you copy the full local folder, it also grabs local plugin caches and stored text.
Can I share my backup file with other developers on my team?
Yes, you can share a clean backup file to give new teammates a standard toolset. First, check that you removed all personal API tokens and database passwords before exporting the file.
How often should engineers back up their launcher settings?
Engineers only need to export their settings after they add new plugins or change core workflows. Exporting once a month or after major workflow updates is enough for most developers.