Free open source alternative app list about topic "rust" :

rtk

rtk is a free, open-source software / service you can self-host or use without paying. High-performance CLI proxy that cuts up to 90% of the bash output your agent reads Website • Install • Troubleshooting • Architecture • Discord English • Francais • 中文 • 日本語 • 한국어 • Espanol • Português rtk filters and compresses command outputs before they reach your LLM context. Single Rust binary, 100+ supported commands, <10ms overhead. What RTK Does RTK intercepts shell commands and compresses their output before your agent reads it. Operation What RTK does to the output ls / tree Tree format with file counts instead of one line per entry cat / read Smart file reading: signatures and structure over full bodies grep / rg Truncates long lines, groups matches by file git status Compact stat format, grouped by state git diff Reduced context, headers stripped git log Hash, author and subject only git add/commit/push Confirmation line instead of full progress output cargo test / npm test Failures only, passing tests collapsed to a count ruff check Grouped by rule and file pytest Failures only, traceback trimmed go test NDJSON parsed, failures only docker ps Essential fields only How Savings Work RTK cuts up to 90% of the bash output your agent reads. That is what RTK measures, and it is not the same as cutting your bill by 90%. Bash output is one contributor to input tokens , alongside your prompt, the system prompt and conversation history. Input tokens are in turn only part of the bill , which also counts output tokens. The reduction dilutes at every step. The token counts RTK reports are estimated as bytes / 4 — RTK ships no tokenizer, so the percentages are reliable but the absolute token numbers are approximate . Full explanation: How RTK Savings Work Installation Homebrew (recommended) brew install rtk Quick Install (Linux/macOS) curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh Installs to ~/.local/bin . Add to PATH if needed: echo ' export PATH="$HOME/.local/bin:$PATH" ' >> ~ /.bashrc # or ~/.zshrc Cargo cargo install --git https://github.com/rtk-ai/rtk Pre-built Binaries Download from releases : macOS: rtk-x86_64-apple-darwin.tar.gz / rtk-aarch64-apple-darwin.tar.gz Linux: rtk-x86_64-unknown-linux-musl.tar.gz / rtk-aarch64-unknown-linux-gnu.tar.gz Windows: rtk-x86_64-pc-windows-msvc.zip Windows users : Extract the zip and place rtk.exe somewhere in your PATH (e.g. C:\Users\<you>\.local\bin ). Run RTK from Command Prompt , PowerShell , or Windows Terminal — do not double-click the .exe (it will flash and close). The full hook system works natively on Windows (and in WSL ). See Windows setup below for details. Verify Installation rtk --version # Should show "rtk 0.28.2" rtk gain # Should show the savings dashboard Name collision warning : Another project named "rtk" (Rust Type Kit) exists on crates.io. If rtk gain fails, you have the wrong package. Use cargo install --git above instead. Quick Start # 1. Install for your AI tool rtk init -g # Claude Code / Copilot (default) rtk init -g --gemini # Gemini CLI rtk init -g --codex # Codex (OpenAI) rtk init -g --agent cursor # Cursor rtk init -g --agent windsurf # Windsurf rtk init --agent cline # Cline / Roo Code rtk init --agent kilocode # Kilo Code rtk init --agent antigravity # Google Antigravity rtk init --agent kimi # Kimi AI rtk init -g --agent pi # Pi rtk init --agent hermes # Hermes rtk init -g --agent droid # Factory Droid # 2. Restart your AI tool, then test git status # Automatically rewritten to rtk git status Hook-based agents rewrite Bash commands (e.g., git status -> rtk git status ) before execution. Plugin-based agents, including Hermes, use their plugin API to rewrite commands before execution. The agent receives compact output without needing to call rtk explicitly. Important: the hook only runs on Bash tool calls. Claude Code built-in tools like Read , Grep , and Glob do not pass through the Bash hook, so they are not auto-rewritten. To get RTK's compact output for those workflows, use shell commands ( cat / head / tail , rg / grep , find ) or call rtk read , rtk grep , or rtk find directly. How It Works Without rtk: With rtk: Claude --git status--> shell --> git Claude --git status--> RTK --> git ^ | ^ | | | full raw output | | compact output | filter | +-----------------------------------+ +------- (filtered) ---+----------+ Four strategies applied per command type: Smart Filtering - Removes noise (comments, whitespace, boilerplate) Grouping - Aggregates similar items (files by directory, errors by type) Truncation - Keeps relevant context, cuts redundancy Deduplication - Collapses repeated log lines with counts Commands Percentages below are reductions in bash output , not reductions in your bill. See How Savings Work . Files rtk ls . # Compact directory tree rtk read file.rs # Smart file reading rtk read file.rs -l aggressive # Signatures only (strips bodies) rtk smart file.rs # 2-line heuristic code summary rtk find " *.rs " . # Compact find results rtk grep " pattern " . # Grouped search results rtk diff file1 file2 # Condensed diff (exit 1 if files differ) Git rtk git status # Compact status rtk git log -n 10 # One-line commits rtk git diff # Condensed diff rtk git add # -> "ok" rtk git commit -m " msg " # -> "ok abc1234" rtk git push # -> "ok main" rtk git pull # -> "ok 3 files +10 -2" GitHub CLI rtk gh pr list # Compact PR listing rtk gh pr view 42 # PR details + checks rtk gh issue list # Compact issue listing rtk gh run list # Workflow run status Test Runners rtk jest # Jest compact (failures only) rtk vitest # Vitest compact (failures only) rtk playwright test # E2E results (failures only) rtk pytest # Python tests (-90%) rtk go test # Go tests (NDJSON, -90%) rtk cargo test # Cargo tests (-90%) rtk rake test # Ruby minitest (-90%) rtk rspec # RSpec tests (JSON, -60%+) rtk err < cmd > # Filter errors only from any command rtk test < cmd > # Generic test wrapper - failures only (-90%) Build & Lint rtk lint # ESLint grouped by rule/file rtk lint biome # Supports other linters rtk tsc # TypeScript errors grouped by file rtk next build # Next.js build compact rtk prettier --check . # Files needing formatting rtk cargo build # Cargo build (-80%) rtk cargo clippy # Cargo clippy (-80%) rtk ruff check # Python linting (JSON, -80%) rtk golangci-lint run # Go linting (JSON, -85%) rtk rubocop # Ruby linting (JSON, -60%+) rtk sbt test # ScalaTest output (-90%) rtk sbt compile # Compilation errors only (-75%) rtk sbt run # Strip SBT preamble noise Package Managers rtk pnpm list # Compact dependency tree rtk uv run pytest # Preserve uv env, keep program output rtk pip list # Python packages (auto-detect uv) rtk pip outdated # Outdated packages rtk bundle install # Ruby gems (strip Using lines) rtk prisma generate # Schema generation (no ASCII art) AWS rtk aws sts get-caller-identity # One-line identity rtk aws ec2 describe-instances # Compact instance list rtk aws lambda list-functions # Name/runtime/memory (strips secrets) rtk aws logs get-log-events # Timestamped messages only rtk aws cloudformation describe-stack-events # Failures first rtk aws dynamodb scan # Unwraps type annotations rtk aws iam list-roles # Strips policy documents rtk aws s3 ls # Truncated with tee recovery Containers rtk docker ps # Compact container list rtk docker images # Compact image list rtk docker logs < container > # Deduplicated logs rtk docker compose ps # Compose services rtk kubectl pods # Compact pod list rtk kubectl logs < pod > # Deduplicated logs rtk kubectl services # Compact service list rtk oc get pods # OpenShift pod summary rtk oc get services # OpenShift service list rtk oc logs < pod > # Deduplicated logs Infrastructure as Code rtk pulumi preview # Strip header/URL/duration noise rtk pulumi up # Compact apply output rtk pulumi destroy # Compact destroy output rtk pulumi refresh # Drift summary rtk pulumi stack # Stack metadata (strips owner/timestamps) Data & Analytics rtk json config.json # Structure without values rtk deps # Dependencies summary rtk env -f AWS # Filtered env vars rtk log app.log # Deduplicated logs rtk curl < url > # Truncate + save full output rtk wget < url > # Download, strip progress bars rtk summary < long command > # Heuristic summary rtk proxy < command > # Raw passthrough + tracking Token Savings Analytics rtk gain # Summary stats rtk gain --graph # ASCII graph (last 30 days) rtk gain --history # Recent command history rtk gain --daily # Day-by-day breakdown rtk gain --all --format json # JSON export for dashboards rtk discover # Find missed savings opportunities rtk discover --all --since 7 # All projects, last 7 days rtk session # Show RTK adoption across recent sessions Global Flags -u, --ultra-compact # ASCII icons, inline format (further output reduction) -v, --verbose # Increase verbosity (-v, -vv, -vvv) Examples Directory listing: # ls -la (45 lines) # rtk ls (12 lines) drwxr-xr-x 15 user staff 480 ... my-project/ -rw-r--r-- 1 user staff 1234 ... +-- src/ (8 files) ... | +-- main.rs +-- Cargo.toml Git operations: # git push (15 lines) # rtk git push (1 line) Enumerating objects: 5, done. ok main Counting objects: 100% (5/5), done. Delta compression using up to 8 threads ... Test output: # cargo test (200+ lines on failure) # rtk test cargo test (~20 lines) running 15 tests FAILED: 2/15 tests test utils::test_parse ... ok test_edge_case: assertion failed test utils::test_format ... ok test_overflow: panic at utils.rs:18 ... Auto-Rewrite Hook The most effective way to use rtk. The hook transparently intercepts Bash commands and rewrites them to rtk equivalents before execution. Result : 100% rtk adoption across all conversations and subagents, with no per-command context overhead. Scope note: this only applies to Bash tool calls. Claude Code built-in tools such as Read , Grep , and Glob bypass the hook, so use shell commands or explicit rtk commands when you want RTK filtering there. Setup rtk init -g # Install hook + RTK.md (recommended) rtk init -g --opencode # OpenCode plugin (instead of Claude Code) rtk init -g --auto-patch # Non-interactive (CI/CD) rtk init -g --hook-only # Hook only, no RTK.md rtk init --show # Verify installation After install, restart Claude Code . Windows RTK works fully on native Windows. Since v0.37.2 the auto-rewrite hook runs as a native binary command ( rtk hook claude ) — no Unix shell, bash, or jq required — so commands are rewritten transparently on Command Prompt, PowerShell, and Windows Terminal, just like on Linux and macOS. Native Windows # 1. Download and extract rtk-x86_64-pc-windows-msvc.zip from releases # 2. Add rtk.exe to your PATH (e.g. C:\Users\<you>\.local\bin) # 3. Initialize — installs the native binary hook rtk init - g Upgrading from an older install? If you set RTK up before v0.37.2 you may still have the legacy rtk-rewrite.sh shell hook (which does need a Unix shell). Re-run rtk init -g to migrate to the native binary hook. Prerequisites : some filters shell out to ripgrep ( rg ). Install it and keep it on your PATH (e.g. winget install BurntSushi.ripgrep.MSVC ) to avoid Binary 'rg' not found on PATH warnings. Important : Do not double-click rtk.exe — it is a CLI tool that prints usage and exits immediately. Always run it from a terminal (Command Prompt, PowerShell, or Windows Terminal). WSL WSL also works and behaves exactly like Linux: # Inside WSL curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh rtk init -g Feature Native Windows WSL Filters (cargo, git, etc.) Full Full Auto-rewrite hook Yes (native binary) Yes rtk init -g Hook mode Hook mode rtk gain / analytics Full Full Supported AI Tools RTK supports 16 AI coding tools. Each integration rewrites shell commands to rtk equivalents, reducing the bash output the agent reads where the agent supports command interception. Tool Install Method Claude Code rtk init -g PreToolUse hook (native binary) GitHub Copilot (VS Code) rtk init -g --copilot PreToolUse hook — transparent rewrite GitHub Copilot CLI rtk init -g --copilot PreToolUse deny-with-suggestion (CLI limitation) Cursor rtk init -g --agent cursor preToolUse hook (hooks.json) Gemini CLI rtk init -g --gemini BeforeTool hook Codex rtk init -g --codex AGENTS.md + RTK.md instructions Windsurf rtk init -g --agent windsurf .windsurfrules (project-scoped) Cline / Roo Code rtk init --agent cline .clinerules (project-scoped) OpenCode rtk init -g --opencode Plugin TS (tool.execute.before) OpenClaw openclaw plugins install ./openclaw Plugin TS (before_tool_call) Pi rtk init -g --agent pi (global) TypeScript extension (tool_call) Hermes rtk init --agent hermes Python plugin adapter (terminal command mutation via rtk rewrite ) Mistral Vibe rtk init -g --agent vibe pre_tool hook (hooks.toml) Kilo Code rtk init --agent kilocode .kilocode/rules/rtk-rules.md (project-scoped) Google Antigravity rtk init --agent antigravity .agents/rules/antigravity-rtk-rules.md (project-scoped) Kimi AI rtk init --agent kimi AGENTS.md (project-scoped) Factory Droid rtk init -g --agent droid (or per-project) PreToolUse hook in ~/.factory/hooks.json (matcher Execute ) For per-agent setup details, override controls, and graceful degradation, see the Supported Agents guide . The Hermes plugin source and tests live in hooks/hermes/ ; installed Hermes runtime files still live under ~/.hermes/plugins/rtk-rewrite/ . Configuration ~/.config/rtk/config.toml (macOS: ~/Library/Application Support/rtk/config.toml ): [ hooks ] exclude_commands = [ " curl " , " playwright " ] # skip rewrite for these [ tee ] enabled = true # save raw output on failure (default: true) mode = " failures " # "failures", "always", or "never" When a command fails, RTK saves the full unfiltered output so the LLM can read it without re-executing: FAILED: 2/15 tests [full output: ~/.local/share/rtk/tee/1707753600_cargo_test.log] For the full config reference (all sections, env vars, per-project filters), see the Configuration guide . Uninstall rtk init -g --uninstall # Remove hook, RTK.md, settings.json entry cargo uninstall rtk # Remove binary brew uninstall rtk # If installed via Homebrew Documentation rtk-ai.app/guide — full user guide (installation, supported agents, what gets optimized, analytics, configuration, troubleshooting) INSTALL.md — detailed installation reference ARCHITECTURE.md — system design and technical decisions CONTRIBUTING.md — contribution guide SECURITY.md — security policy Privacy & Telemetry RTK can collect anonymous, aggregate usage metrics once per day. Telemetry is disabled by default and requires explicit opt-in consent (GDPR Art. 6, 7) during rtk init or via rtk telemetry enable . This data helps us build a better product: identifying which commands need filters, which filters need improvement, and how much value RTK delivers. For the full list of fields, data handling, and contributor guidelines, see docs/TELEMETRY.md . What is collected and why: Category Data Why Identity Salted device hash (SHA-256, not reversible) Count unique installations without tracking individuals Environment RTK version, OS, architecture, install method Know which platforms to support and test Usage volume Command count (24h), total commands, estimated tokens saved (24h/30d/total) Measure adoption and value delivered Quality Top 5 passthrough commands (0% reduction), parse failure count, commands with <30% reduction Identify missing filters and weak ones to improve Ecosystem Command category distribution (e.g. git 45%, cargo 20%, js 15%) Prioritize filter development for popular ecosystems Retention Days since first use, active days in last 30 Understand engagement and detect churn Adoption AI agent hook type (claude/gemini/codex), custom TOML filter count Track integration coverage and DSL adoption Configuration Whether config.toml exists, number of excluded commands, project count Understand user maturity and customization patterns Features Usage counts for meta-commands (gain, discover, proxy, verify) Know which RTK features are valued vs unused Economics Estimated USD value, derived from the estimated tokens saved and a fixed internal constant Quantify the value RTK provides to users All data is aggregate counts or anonymized command names (first 3 words, no arguments). Top commands report only tool names (e.g. "git", "cargo"), never full command lines. What is NOT collected: source code, file paths, command arguments, secrets, environment variables, personal data, or repository contents. Manage telemetry: rtk telemetry status # Check current consent state rtk telemetry enable # Give consent (interactive prompt) rtk telemetry disable # Withdraw consent — stops all collection immediately rtk telemetry forget # Withdraw consent + delete all local data + request server-side erasure Override via environment: export RTK_TELEMETRY_DISABLED=1 # Blocks telemetry regardless of consent Star History StarMapper Core team Patrick Szymkowiak — Founder GitHub · LinkedIn Florian Bruniaux — Core contributor GitHub · LinkedIn Adrien Eppling — Core contributor GitHub · LinkedIn Nicolas Le Cam — Core contributor Github · LinkedIn Takayuki Maeda — Core contributor GitHub · LinkedIn Contributing Contributions welcome! Please open an issue or PR on GitHub . Join the community on Discord . License Apache License 2.0 - see LICENSE for details. Disclaimer See DISCLAIMER.md .

FreeWindowsmacOSLinux

hyperswitch

hyperswitch is a free, open-source alternative to Stripe . Composable Open-Source Payments Infrastructure 📁 Table of Contents What Can I Do with Hyperswitch? Quickstart (Local Setup) Cloud Deployment Hosted Sandbox (No Setup Required) Why Hyperswitch? Architectural Overview Our Vision Community & Contributions Feature Requests & Bugs Versioning License Team Behind Hyperswitch What Can I Do with Hyperswitch? Hyperswitch offers a modular, open-source payments infrastructure designed for flexibility and control. Apart from our Payment Suite offering, this solution allows businesses to pick and integrate only the modules they need on top of their existing payment stack — without unnecessary complexity or vendor lock-in. Each module is independent and purpose-built to optimize different aspects of payment processing. Learn More About The Payment Modules Details Cost Observability Advanced observability tools to audit, monitor, and optimize your payment costs. Detect hidden fees, downgrades, and penalties with self-serve dashboards and actionable insights. Read more Revenue Recovery Combat passive churn with intelligent retry strategies tuned by card bin, region, method, and more. Offers fine-grained control over retry algorithms, penalty budgets, and recovery transparency. Read more Vault A PCI-compliant vault service to store cards, tokens, wallets, and bank credentials. Provides a unified, secure, and reusable store of customer-linked payment methods. Also supports bring-your-own-vault to connect existing providers including VGS and TokenEx without re-tokenizing or migrating stored cards. Read more Intelligent Routing Route each transaction across Stripe, Adyen, Braintree, Worldpay, Checkout.com, and 120+ others to the PSP with the highest predicted auth rate. Reduce retries, avoid downtime, and minimize latency while maximizing first attempt success. Read more Reconciliation Automate 2-way and 3-way reconciliation with backdated support, staggered scheduling, and customizable outputs. Reduces manual ops effort and increases audit confidence. Read more Alternate Payment Methods Drop-in widgets for PayPal, Apple Pay, Google Pay, Samsung Pay, Pay by Bank, and BNPL providers like Klarna. Maximizes conversions with seamless one-click checkout. Read more Quickstart Local Setup via Docker # One-click local setup git clone --depth 1 --branch latest https://github.com/juspay/hyperswitch cd hyperswitch scripts/setup.sh This script: Detects Docker/Podman Offers multiple deployment profiles: Standard : App server + Control Center Full : Includes monitoring + schedulers Minimal : Standalone App server Provides access links when done If you need further help, check out our video tutorial . 👉 After setup, configure a connector and test a payment . Hosted Sandbox (No Setup Required) Hyperswitch offers a fully hosted sandbox environment that requires no setup. You can explore the Control Center, configure payment connectors, and test payments directly from the UI. What you can do in the Hosted Sandbox Access the full Control Center Configure payment connectors View logs, routing rules, and retry strategies Try payments directly from the UI Cloud Deployment You can deploy to AWS, GCP, or Azure using Helm Charts. Cloud Deployment Instructions . Architectural Overview Why Hyperswitch? Hyperswitch is a commercial open-source payments stack purpose-built for scale, flexibility, and developer experience. Designed with a modular architecture, Hyperswitch lets you pick only the components you need—whether it’s routing, retries, vaulting, or observability—without vendor lock-in or bloated integrations. Built in Rust for performance and reliability, Hyperswitch connects to Stripe, Adyen, Braintree, Worldpay, Checkout.com, Cybersource, and 120+ processors — exposing smart routing and retry logic, and provides a visual workflow builder in the Control Center. Whether you're integrating a full payment suite or augmenting an existing stack with a single module, Hyperswitch meets you where you are. Common starting points: teams moving from a single Stripe/ Stripe connect or Braintree integration to multi-PSP routing, merchants replacing a payment gateway with direct acquirer connections to TSYS, JP Morgan Payments, or other acquirers, and merchants rearchitecting their payments platform through Hyperswitch while keeping their existing VGS, TokenEx or other existing vault intact. “Linux for Payments” — Hyperswitch is a well-architected reference for teams who want to own their payments stack. We believe in: Embracing Payment Diversity: Innovation comes from enabling choice—across payment methods, processors, and flows. Open Source by Default: Transparency drives trust and builds better, reusable software. Community-Driven Development: Our roadmap is shaped by real-world use cases and contributors. Systems-Level Engineering: We hold ourselves to a high bar for reliability, security, and performance. Maximizing Value Creation: For developers, customers, and partners alike. Community-Driven, Enterprise-Tested: Hyperswitch is built in the open with real-world feedback from developers and contributors, and maintained by Juspay, the team powering payment infrastructure for 400+ leading enterprises worldwide. Supported Connectors Hyperswitch integrates with 100+ payment processors out of the box. Each connector has a dedicated guide covering credentials setup, webhook configuration, supported payment methods, and common failure modes. Processor Type Guide Global Payments Payment Gateway View → Stripe Payment Gateway View → Paypal Payment Gateway View → Adyen Payment Gateway View → Bank of America Payment Gateway View → 👉 Browse all available connectors → Hyperswitch Ecosystem Mapping Hyperswitch is built as a set of modular services and SDKs that work together. The Rust app server in this repo is the core, and the repositories below extend it with dashboards, client SDKs, and deployment tooling. 1. Core backend services The Rust services that process payments. The app server is the center of gravity; the vault and encryption service handle sensitive-data operations alongside it. hyperswitch-prism is a separate, lighter entry point: a unified connector library that can be used directly against payment processors without running the full switch. decision-engine is another standalone service: a routing control plane that selects the best gateway per transaction and can run independently of any orchestrator. hyperswitch card-vault encryption-service prism decision-engine Language Rust Rust Rust Rust Rust Role App server. Routing, retries, vaulting, observability. PCI-compliant card storage. Encryption, decryption, KMS. Unified connector library, 100+ processors. Routing control plane. Rule-based and success-rate gateway selection. Standalone, works with any orchestrator. Depends on card-vault, encryption-service encryption-service None None None 2. Dashboard Merchant-facing UIs for configuring connectors, routing, and viewing transactions. Both require the hyperswitch backend to be running. control-center control-center-embedded Language ReScript TypeScript Role Full merchant dashboard. Connectors, routing rules, analytics, API keys. Embeddable Hyperswitch components for partners and merchants surfacing Hyperswitch UI inside their own apps. Depends on hyperswitch backend hyperswitch backend 3. Web checkout SDKs How a browser talks to Hyperswitch. hyperswitch-client-core is the shared core, pulled in as a git submodule by every client SDK (web and mobile). hyperswitch-sdk-utils holds shared assets that merchants doing Headless Implementations consume directly. hyperswitch-web client-core react-hyper-js sdk-utils Language ReScript ReScript ReScript ReScript Distribution npm git submodule npm git submodule Role Primary web SDK. ReScript-built React library for unified checkout. Shared SDK core consumed transitively by every client SDK. Idiomatic React wrapper around the Hyper JS loader. Shared utilities and assets used across client-core and hyperswitch-web. Depends on hyperswitch backend None hyperswitch-web None 4. Mobile SDKs Native SDKs for embedding Hyperswitch checkout into mobile apps. All are built on top of hyperswitch-client-core , pulled in as a git submodule. Android iOS React Native Flutter Repository hyperswitch-sdk-android hyperswitch-sdk-ios react-native-hyperswitch flutter_hyperswitch Language Kotlin Swift TypeScript Dart Distribution Maven CocoaPods (SPM in progress) npm pub.dev Status Officially supported Officially supported Officially supported Officially supported Important An older repo, hyperswitch-sdk-react-native , is being deprecated and has already been removed from npm. Use react-native-hyperswitch instead. 5. Deployment & infrastructure Tooling for running Hyperswitch, from local development through production. hyperswitch-suite hyperswitch-helm Tooling Terraform (HCL) Helm charts Role Umbrella full-suite deployment that wires the core, vault, control-center, and web together. Recommended starting point for the full stack. Kubernetes deployments for GCP, Azure, or any K8s-compatible platform. Contributing We welcome contributors from around the world to help build Hyperswitch. Whether you're fixing bugs, improving documentation, or adding new features, your help is appreciated. Please read our contributing guidelines to get started. Join the conversation on Slack or explore open issues on GitHub . Feature requests & Bugs For new product features, enhancements, roadmap discussions, or to share queries and ideas, visit our GitHub Discussions For reporting a bug, please read the issue guidelines and search for existing and closed issues . If your problem or idea is not addressed yet, please open a new issue . Versioning Check the CHANGELOG.md file for details. Copyright and License This product is licensed under the Apache 2.0 License .

FreeWindowsmacOSLinuxAndroidiOS

bevy

bevy is a free, open-source alternative to Unity . What is Bevy? Bevy is a refreshingly simple data-driven game engine built in Rust. It is free and open-source forever! WARNING Bevy is still in the early stages of development. Important features are missing. Documentation is sparse. A new version of Bevy containing breaking changes to the API is released approximately once every 3 months . We provide migration guides , but we can't guarantee migrations will always be easy. Use only if you are willing to work in this environment. MSRV: Bevy relies heavily on improvements in the Rust language and compiler. As a result, the Minimum Supported Rust Version (MSRV) is generally close to "the latest stable release" of Rust. Design Goals Capable : Offer a complete 2D and 3D feature set Simple : Easy for newbies to pick up, but infinitely flexible for power users Data Focused : Data-oriented architecture using the Entity Component System paradigm Modular : Use only what you need. Replace what you don't like Fast : App logic should run quickly, and when possible, in parallel Productive : Changes should compile quickly ... waiting isn't fun About Features : A quick overview of Bevy's features. News : A development blog that covers our progress, plans and shiny new features. Docs Quick Start Guide : Bevy's official Quick Start Guide. The best place to start learning Bevy. Bevy Rust API Docs : Bevy's Rust API docs, which are automatically generated from the doc comments in this repo. Official Examples : Bevy's dedicated, runnable examples, which are great for digging into specific concepts. Community-Made Learning Resources : More tutorials, documentation, and examples made by the Bevy community. Community Before contributing or participating in discussions with the community, you should familiarize yourself with our Code of Conduct . Discord : Bevy's official discord server. Reddit : Bevy's official subreddit. GitHub Discussions : The best place for questions about Bevy, answered right here! Bevy Assets : A collection of awesome Bevy projects, tools, plugins and learning materials. Contributing If you'd like to help build Bevy, check out the Contributor's Guide . For simple problems, feel free to open an issue or PR and tackle it yourself! For more complex architecture decisions and experimental mad science, please open a GitHub Discussion so we can brainstorm together effectively! Getting Started We recommend checking out the Quick Start Guide for a brief introduction. Follow the Setup guide to ensure your development environment is set up correctly. Once set up, you can quickly try out the examples by cloning this repo and running the following commands: # Switch to the correct version (latest release, default is main development branch) git checkout latest # Runs the "breakout" example cargo run --example breakout To draw a window with standard functionality enabled, use: use bevy :: prelude :: * ; fn main ( ) { App :: new ( ) . add_plugins ( DefaultPlugins ) . run ( ) ; } Fast Compiles Bevy can be built just fine using default configuration on stable Rust. However for really fast iterative compiles, you should enable the "fast compiles" setup by following the instructions here . Bevy Cargo Features This list outlines the different cargo features supported by Bevy. These allow you to customize the Bevy feature set for your use-case. Thanks Bevy is the result of the hard work of many people. A huge thanks to all Bevy contributors, the many open source projects that have come before us, the Rust gamedev ecosystem , and the many libraries we build on. A huge thanks to Bevy's generous sponsors . Bevy will always be free and open source, but it isn't free to make. Please consider sponsoring our work if you like what we're building. This project is tested with BrowserStack. License Bevy is free, open source and permissively licensed! Except where noted (below and/or in individual files), all code in this repository is dual-licensed under either: MIT License ( LICENSE-MIT or http://opensource.org/licenses/MIT ) Apache License, Version 2.0 ( LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0 ) at your option. This means you can select the license you prefer! This dual-licensing approach is the de-facto standard in the Rust ecosystem and there are very good reasons to include both. Some of the engine's code carries additional copyright notices and license terms due to their external origins. These are generally BSD-like, but exact details vary by crate: If the README of a crate contains a 'License' header (or similar), the additional copyright notices and license terms applicable to that crate will be listed. The above licensing requirement still applies to contributions to those crates, and sections of those crates will carry those license terms. The license field of each crate will also reflect this. The assets included in this repository (for our examples ) typically fall under different open licenses. These will not be included in your game (unless copied in by you), and they are not distributed in the published bevy crates. See CREDITS.md for the details of the licenses of those files. Your contributions Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

FreeWindowsmacOSLinuxAndroidiOS

spacedrive

spacedrive is a free, open-source alternative to ExpanDrive . Spacedrive One file manager for all your devices and clouds. Powered by a Virtual Distributed File System, complete with apps for macOS, Windows, Linux, iOS and Android v2.spacedrive.com • Discord • Getting Started What is Spacedrive? Spacedrive is a cross-device data platform. Index files, emails, notes, and external sources. Search everything. Sync via P2P. Keep AI agents safe with built-in screening. Content identity — every file gets a BLAKE3 content hash. Same file on two devices produces the same hash. Spacedrive tracks redundancy and deduplication across all your machines. Cross-device — see all your files across all your devices in one place. Files on disconnected devices stay in the index and appear as offline. P2P sync — devices connect directly via Iroh/QUIC. No servers, no cloud, no single point of failure. Metadata syncs between devices. Files stay where they are. Cloud volumes — index S3, Google Drive, Dropbox, OneDrive, Azure, and GCS as first-class volumes alongside local storage. Nine views — grid, list, columns, media, size, recents, search, knowledge, and splat. QuickPreview for video, audio, code, documents, 3D, and images. Local-first — everything runs on your machine. No data leaves your device unless you choose to sync between your own devices. Is this a replacement for Finder or Explorer? No. Spacedrive sits above your OS file manager and adds capabilities Finder/Explorer lack: Portal across everything — search and browse files across local disks, external drives, NAS, cloud storage, and archived data sources from one interface. Operating surface for files — content identity, sidecars, derivative artifacts, rich metadata, sync, and cross-device awareness built into the core model. Embeddable and shareable — run it as a desktop app, headless server, hosted file service, or embed the interface and APIs into other products. AI-ready by design — indexing and analysis pipelines prepare data ahead of time instead of giving agents raw shell access. Safer access model — route AI and automation through structured APIs, permissions, and processing layers instead of direct file operations. You still use your OS for low-level file interactions. Spacedrive adds the cross-platform, cross-device, cloud-aware, and automation-friendly layer on top. Data Archival Spacedrive indexes external data sources via script-based adapters: Gmail, Apple Notes, Chrome bookmarks, Obsidian, Slack, GitHub, calendar events, contacts. Each source becomes a searchable repository alongside your files. Adapters are a folder with an adapter.toml manifest and a sync script in any language. If it reads stdin and prints lines, it works. Shipped adapters: Gmail, Apple Notes, Chrome Bookmarks, Chrome History, Safari History, Obsidian, OpenCode, Slack, macOS Contacts, macOS Calendar, GitHub. Spacebot Spacedrive integrates with Spacebot , an open source AI agent runtime. Spacebot runs as an optional separate process. Spacedrive provides the data, permission, and execution layer. Spacebot provides the intelligence. Each Spacebot instance pairs with one Spacedrive node as its home device. That node authenticates the agent, maintains the device graph, resolves permissions, and forwards operations to peer devices. Every device in your library can reach Spacebot through the paired node over P2P (Iroh/QUIC) without direct network access. One agent runtime serves your entire device fleet. When Spacebot spawns a worker, that worker can target any device in the library. File reads, shell commands, and operations proxy through Spacedrive to the target device. Talk to the agent from your phone while work executes on a server. Read files from a NAS, run commands on a workstation, report to a laptop — all in one task. Every operation passes through Spacedrive's permission system: which devices the agent can access, which paths are readable or writable, which operations are allowed, and which require human confirmation. The paired node resolves effective policy before forwarding. One security model, one audit surface across all devices and clouds. File System Intelligence Spacedrive adds intelligence to your filesystem by combining three layers: File intelligence — derivative data like OCR, transcripts, extracted metadata, thumbnails, previews, classifications, and sidecars. Directory intelligence — contextual knowledge attached to folders and subtrees ("active projects", "dormant archives", etc). Access intelligence — permissions and policy that apply across devices and clouds, routing agents through structured access instead of raw shell commands. When an agent navigates through Spacedrive, it receives the file listing, subtree context, effective permissions, and summaries. Users can explain how they organize their system. Agents can add attributed notes. Jobs generate summaries from structure and activity. The intelligence stays attached to the filesystem, not buried in temporary session memory. Safety Screening When enabled, every record passes through a safety pipeline before becoming searchable: Prompt Guard 2 — local classifier detects prompt injection in emails, messages, and documents before they enter the index. Trust tiers — authored content (your notes) gets balanced screening, external content (email inbox) gets strict screening. Quarantine system — flagged records excluded from AI agent queries, reviewable in desktop app. Content fencing — search results include trust metadata so agents know what's safe vs untrusted. No other local data tool screens indexed content before exposing it to AI. Architecture The core is built on four principles: Virtual Distributed Filesystem (VDFS) — files and folders become first-class objects with rich metadata, independent of physical location. Every file gets a universal address ( SdPath ) that works across devices. Content Identity System — adaptive hashing (BLAKE3 with strategic sampling for large files) creates a unique fingerprint for every piece of content. Enables deduplication, redundancy tracking, and content-based operations. Transactional Actions — every file operation can be previewed before execution. See space savings, conflicts, and estimated time, then approve or cancel. Operations become durable jobs that survive network interruptions and device restarts. Leaderless Sync — peer-to-peer synchronization without central coordinators. Device-specific data uses state replication. Shared metadata uses an HLC-ordered log with deterministic conflict resolution. The implementation is a single Rust crate with CQRS/DDD architecture. Every operation (file copy, tag create, search query) is a registered action or query with type-safe input/output that auto-generates TypeScript types for the frontend. Component Technology Language Rust Async runtime Tokio Database SQLite (SeaORM + sqlx) P2P Iroh (QUIC, hole-punching, local discovery) Content hashing BLAKE3 Vector search LanceDB + FastEmbed Cloud storage OpenDAL Cryptography Ed25519, X25519, ChaCha20-Poly1305, AES-GCM Media FFmpeg, libheif, Pdfium, Whisper Desktop Tauri 2 Mobile React Native + Expo Frontend React 19, Vite, TanStack Query, Tailwind CSS v4 Design system SpaceUI (shared component library) Type generation Specta spacedrive/ ├── core/ # Rust engine (CQRS/DDD) ├── apps/ │ ├── tauri/ # Desktop app (macOS, Windows, Linux) │ ├── mobile/ # React Native (iOS, Android) │ ├── cli/ # CLI and daemon │ ├── server/ # Headless server │ └── web/ # Browser client ├── packages/ │ ├── interface/ # Shared React UI │ ├── ts-client/ # Auto-generated TypeScript client │ ├── ui/ # Component library │ └── assets/ # Icons, images, SVGs ├── crates/ # Standalone Rust crates (ffmpeg, crypto, etc.) ├── adapters/ # Script-based data source adapters └── schemas/ # TOML data type schemas Getting Started Requires Rust 1.81+, Bun 1.3+, just , and Python 3.9+ (for adapters). git clone https://github.com/spacedriveapp/spacedrive cd spacedrive just setup # bun install + native deps + cargo config just dev-desktop # launch the desktop app (auto-starts daemon) just test # run all workspace tests Privacy & Security Spacedrive is local-first. Your data stays on your devices. End-to-End Encryption — all P2P traffic encrypted via QUIC/TLS At-Rest Encryption — libraries can be encrypted on disk (SQLCipher) No Telemetry — zero tracking or analytics Self-Hostable — run your own relay servers Data Sovereignty — you control where your data lives Optional cloud integration is available for backup and remote access, but it's never required. The cloud service runs unmodified Spacedrive core as a standard P2P device—no special privileges. Contributing Join Discord to chat with developers and community Contributing Guide Adapter Guide — write a data source adapter SpaceUI — shared design system (clone alongside Spacedrive to work on UI) License FSL-1.1-ALv2 — Functional Source License , converting to Apache 2.0 after two years.

FreeWindowsmacOSLinuxAndroidiOS

firecracker

firecracker is a free, open-source software / service you can self-host or use without paying. Our mission is to enable secure, multi-tenant, minimal-overhead execution of container and function workloads. Read more about the Firecracker Charter here . What is Firecracker? Firecracker is an open source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services that provide serverless operational models. Firecracker runs workloads in lightweight virtual machines, called microVMs, which combine the security and isolation properties provided by hardware virtualization technology with the speed and flexibility of containers. Overview The main component of Firecracker is a virtual machine monitor (VMM) that uses the Linux Kernel Virtual Machine (KVM) to create and run microVMs. Firecracker has a minimalist design. It excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM. This improves security, decreases the startup time, and increases hardware utilization. Firecracker has also been integrated in container runtimes, for example Kata Containers and Flintlock . Firecracker was developed at Amazon Web Services to accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate . Firecracker is open sourced under Apache version 2.0 . To read more about Firecracker, check out firecracker-microvm.io . Getting Started To get started with Firecracker, download the latest release binaries or build it from source. You can build Firecracker on any Unix/Linux system that has Docker running (we use a development container) and bash installed, as follows: git clone https://github.com/firecracker-microvm/firecracker cd firecracker tools/devtool build toolchain= " $( uname -m ) -unknown-linux-musl " The Firecracker binary will be placed at build/cargo_target/${toolchain}/debug/firecracker . For more information on building, testing, and running Firecracker, go to the quickstart guide . The overall security of Firecracker microVMs, including the ability to meet the criteria for safe multi-tenant computing, depends on a well configured Linux host operating system. A configuration that we believe meets this bar is included in the production host setup document . Contributing Firecracker is already running production workloads within AWS, but it's still Day 1 on the journey guided by our mission . There's a lot more to build and we welcome all contributions. To contribute to Firecracker, check out the development setup section in the getting started guide and then the Firecracker contribution guidelines . Releases New Firecracker versions are released via the GitHub repository releases page, typically every two or three months. A history of changes is recorded in our changelog . The Firecracker release policy is detailed here . Design Firecracker's overall architecture is described in the design document . Features & Capabilities Firecracker consists of a single micro Virtual Machine Manager process that exposes an API endpoint to the host once started. The API is specified in OpenAPI format . Read more about it in the API docs . The API endpoint can be used to: Configure the microvm by: Setting the number of vCPUs (the default is 1). Setting the memory size (the default is 128 MiB). Configuring a CPU template . Add one or more network interfaces to the microVM. Add one or more read-write or read-only disks to the microVM, each represented by a file-backed block device. Trigger a block device re-scan while the guest is running. This enables the guest OS to pick up size changes to the block device's backing file. Change the backing file for a block device, before or after the guest boots. Configure rate limiters for virtio devices which can limit the bandwidth, operations per second, or both. Configure the logging and metric system. [BETA] Configure the data tree of the guest-facing metadata service. The service is only available to the guest if this resource is configured. Add a vsock socket to the microVM. Add a entropy device to the microVM. Add a pmem device to the microVM. Configure and manage memory hotplugging . [Developer Preview] Hot-plug and hot-unplug virtio PCI devices while the VM is running. Start the microVM using a given kernel image, root file system, and boot arguments. [x86_64 only] Stop the microVM. Built-in Capabilities : Demand fault paging and CPU oversubscription enabled by default. Advanced, thread-specific seccomp filters for enhanced security. Jailer process for starting Firecracker in production scenarios; applies a cgroup/namespace isolation barrier and then drops privileges. Tested platforms We test all combinations of: Instance Host OS & Kernel Guest Rootfs Guest Kernel m5n.metal (Intel Cascade Lake) al2 linux_5.10 ubuntu 24.04 linux_5.10 m6i.metal (Intel Ice Lake) al2023 linux_6.1 linux_6.1 al2023 linux_6.18 m7i.metal-24xl (Intel Sapphire Rapids) m7i.metal-48xl (Intel Sapphire Rapids) m8i.metal-48xl (Intel Granite Rapids)* m8i.metal-96xl (Intel Granite Rapids)* m6a.metal (AMD Milan) m7a.metal-48xl (AMD Genoa) m6g.metal (Graviton 2) m7g.metal (Graviton 3) m8g.metal-24xl (Graviton 4) m8g.metal-48xl (Graviton 4) * : We only support AWS EC2 8th Gen Intel (*8i) instances using a 6.1 or 6.18 host kernel. This is due to poor kernel support for Granite Rapids CPUs on 5.10. Known issues and Limitations The pl031 RTC device on aarch64 does not support interrupts, so guest programs which use an RTC alarm (e.g. hwclock ) will not work. Performance Firecracker's performance characteristics are listed as part of the specification documentation . All specifications are a part of our commitment to supporting container and function workloads in serverless operational models, and are therefore enforced via continuous integration testing. Policy for Security Disclosures The security of Firecracker is our top priority. If you suspect you have uncovered a vulnerability, contact us privately, as outlined in our security policy document ; we will immediately prioritize your disclosure. FAQ & Contact Frequently asked questions are collected in our FAQ doc . You can get in touch with the Firecracker community in the following ways: Security-related issues, see our security policy document . Chat with us on our Slack workspace Note: most of the maintainers are on a European time zone. Open a GitHub issue in this repository. Email the maintainers at [email protected] . When communicating within the Firecracker community, please mind our code of conduct .

FreeLinux

Editor's Picks for Free Open-Source Software: