Console
Devtool reviews
Each week Console reviews the best tools for developers.
✦ Disclosure: All reviews are editorially independent and partners must meet our selection criteria.
Latest Tools(100)
What we like: Makes HTTP requests to defined services for load testing. Fully configurable requests (body, headers, TLS certs. Supports HTTP/1.x and HTTP/2.0. Choose request volume: rate, concurrency, duration. Outputs latency numbers. Configurable output templates. Written in Go so available cross platform as a single binary.
What we don't like: Docs are limited - more examples would be useful. It’s designed as a CLI, so you can’t template your test parameters easily.
What we like: Produce and consume messages using a fault-tolerant actor model. Supports distributed communication over the network. Various built-in components e.g. web handler, error handling, state management. Built-in service discovery. Built-in observer UI. Inspired by Erlang (implemented in Go) and interoperable with it.
What we don't like: It appears more complicated to get started that it is - it’s missing a quick start guide with a real world application in the docs, but the CLI can generate example scaffolding for you to get going.
What we like: Parses OpenAPI or AsyncAPI formats to auto-generate SDKs (JS, Python, Go, .NET, Java, Ruby) and docs. Use Fern’s own definition format for more control (can be exported to OpenAPI). Can auto-publish to npm, PyPI, NuGet and Maven Central. Generates a changelog. Integrates with pull request reviews.
What we don't like: Support for PHP, Swift, Rust & Terraform not available yet.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: CLI-driven template workspaces, like GitHub Codespaces, but self-hosted. Works locally with Docker, but can also provision and orchestrate on top of AWS, DigitalOcean, and Fly. Can auto-generate your environment template by inspecting the project, but also supports devcontainers. Prebuilds speed up new environment creation.
What we don't like: Prebuilds require a public webhook, so local support is limited.
What we like: Stateless streaming with no partitions to manage - scale by adding more agents (running in containers). Works with S3 and compatible object storage. Kafka-protocol compatible for drop-in replacement. Avoids inter-zone networking to minimize network costs. Avoids data loss by waiting for writes to object storage to succeed before returning.
What we don't like: End to end producer to consumer p99 latency of ~1 sec. Schema validation & autoscaling in beta.
What we like: User management (free up to 1 million users) backend with support for social auth, magic auth, multi-factor, SSO (SAML or OIDC with directory sync). Users can belong to organizations for multi-account support. AuthKit framework provides themeable UI components for everything. Supports invite-only signup. SDKs for frontend & backend.
What we don't like: No support for passkeys or FIDO security keys. Fine grained authorization functionality still in early access.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Web management UI for Docker - manage running containers from your web browser. Supports all major actions - start, restart, open a shell, inspect logs. Full management of stacks, images, containers, volumes, networks. Keyboard and mouse navigation. Responsive layout for mobile. Works with multiple nodes. Single Go binary.
What we don't like: Has authentication, but don’t just put this online! Restrict it so it’s only accessible via something like Tailscale.
What we like: Runs containers or uses Buildpacks so it’s easy to deploy any type of application. Handles automatic SSL. Easily deploy anything with git. Everything is managed via a CLI. Use various proxies e.g. HAProxy, Caddy, Traefik. Customizable schedulers: Docker, k3s, Nomad. Official GitHub Action for pushing from GitHub.
What we don't like: No web UI - that’s available if you buy Dokku Pro, but it’s still in development.
What we like: Create complex authorization policies based on attributes and roles. SDKs for a wide variety of languages. Supports policy as code with Open Policy Agent and AWS Cedar. Can integrate at the gateway level (Kong, AWS API Gateway, Nginx, etc). Prebuilt UI components for allowing users to manage permissions.
What we don't like: Doesn’t handle authentication - you need to connect it to an auth provider. UI has no dark mode.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Shows everything that makes outbound connections. Allows you to control and review what is talking to who. Granular controls for allowing/denying by IP, hostname, process. Knows when binaries change so you can review rules. Can import regularly updating block lists e.g. known malware hosts. Has explainers for common programs so you know what they are.
What we don't like: Very noisy after you first install it - reveals how much is actually making outbound connections! Binary change alerts can be annoying if you’re developing code that compiles.
What we like: Built directly into Zed so it’s seamless if you’re already using it as your editor. Slash commands allow you to bring in specific context e.g. tab, file, terminal output. You can create custom prompts and ask it to fetch contents from a URL. Can also be triggered in-line from within a source file and from the terminal. Workflows provide step by step instructions.
What we don't like: Obviously requires you to use Zed as your editor. The assistant UI is a fully editable view which gives you control, but takes a bit of getting used to.
What we like: Standard editor features like syntax highlighting, multiple cursors, remote file editing. Based around a UI model with windows and columns with extensive, efficient mouse support e.g. click and drag windows. Scrolling behavior is more useful for code editing. Retro built-in fixed-width font. Custom language for text operations. Has a REST API.
What we don't like: No official support for macOS (works on Linux & Windows). Is open source, but source isn’t on a code hosting provider (it is downloadable though).
What we like: Provides a consistent interface on top of Redis, MongoDB or Postgres - focuses on the queue semantics rather than implementing persistence, HA, load balancing. Queues can be managed - insert, schedule, get, remove. Pipelines support atomic workflows across steps.
What we don't like: Different backends support different features with performance tradeoffs.
What we like: Provides a similar interface to Git (and can interface with Git repos and GitHub pull requests), but uses a stack concept rather than local branches. First-class undo commands. Built-in web UI for reviewing stacks on top of GitHub PRs. Designed for very large monorepos. Doesn’t require everyone to migrate.
What we don't like: Is not “distributed” like Git - has more of a client/server model.
What we like: Maps out all dependencies and shows blast radius analysis for change plans in Terraform. Understands AWS and k8s resources so can represent the changes related to your cloud deployment. Syncs with AWS using a restricted IAM policy. Highlights risks of the proposed change e.g. misconfigured health checks. Can run as part of pull requests.
What we don't like: Currently only integrates with Terraform, AWS, k8s.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Composable pipes allow constructing workflows across LLMs. Can be tied into a 10 million token context window memory and a managed RAG store. Supports multiple LLM APIs and provides cost estimates across them so you can easily mix and match depending on budget. JSON mode enforces response format. Usage analytics & logs make it easy to figure out what’s going on.
What we don't like: Uploaded documents must have selectable text otherwise they can’t be analyzed. Memory only supports plain text formats for now.
What we like: Select the network interface to inspect and visualize traffic. Cross-platform GUI. Shows stats and real-time graphs. Identifies the upstream service e.g. GitHub, and can highlight suspicious traffic e.g. botnets or malware. Notifications on specific events. Can export pcap. Available via multiple package managers as well as downloadable binaries. Open source.
What we don't like: Non-native UI, but it’s not Electron!
What we like: A single test suite that can run the same tests against Node, Bun & Deno. Includes functions for assertions, setup and teardown. Helper functions for common tasks such as building and running containers, waiting for ports to respond, loading environment variables. Can watch for changes and re-run tests. Open source
What we don't like: Incomplete support for mocking, stubbing, and spying. Would like to see more runtime support e.g. Vercel Edge runtime & Cloudflare.
What we like: Drop-in replacement for ls. Full color support for different list types. Visualizes Git status. Can display files in a grid or tree and can recurse directories. View filters e.g. only show directories, exclude symlinks, follow .gitignore. Customizable columns to show filesystem metadata. Forked from the now unmaintained exa project.
What we don't like: Lacks persistent configurability e.g. via a config file - this is coming in the next release.
What we like: Makes it easy to set up form field input masks for correct formatting e.g. phone numbers, IP addresses, hex colors, money. Works with a query selector or element. Masks can be accessed programmatically to retrieve the masked or unmasked value, and validate whether a value is complete. Zero dependencies.
What we don't like: Should work in any framework, but has specific support for Vue, Svelte & Alpine - more native integrations would be good to see.
What we like: Build product experiments with feature flags and testing scenarios. Set up dynamic configs which can be modified in real time from the dashboard. Includes session replays and web analytics in the same product. Send arbitrary metrics for analysis and building experiments around. Can also be managed via a CLI.
What we don't like: Requires additional setup to integrate if you already have a data warehouse of metrics for storage and analysis of experiment data.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Deploy a single binary to set up an S3 compatible object storage server. Designed for data redundancy across multiple nodes. Doesn’t assume a fast network - can be deployed on commodity servers (cloud, VMs, bare metal, etc) - and doesn’t require high spec servers. Use any existing S3 client. Open source.
What we don't like: Cluster operations must be executed carefully to avoid inconsistent state. S3 clients are ubiquitous, but are overly complex for simple operations.
What we like: Query, join, export, import data from databases, Excel, CSV. Inspect and visualize metadata e.g. table structure. Diff rows and tables within databases. Import across formats e.g. Excel into Postgres. Copy, truncate, drop tables. Plugin system for sources. Open source.
What we don't like: No drivers yet for cloud or NoSQL databases e.g. BigQuery, ClickHouse, MongoDB, Redis.
What we like: Faster runners using more up to date CPUs. Supports faster caching of jobs (up to 400MB/s vs GitHub 100MB/s) and colocation of caching physically closer to the runners. Includes a Docker pull-through cache. Cheaper runner costs. Custom caching actions optimized for Rust, Gradle, Zig. NVMe backed I/O.
What we don't like: Doesn’t support personal GitHub accounts. No Windows or macOS runners.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Converts Markdown content into a fully-featured website with a digital garden philosophy. Includes search, graph view, wikilinks, backlinks, Latex, syntax highlighting, RSS. Generates static output that can be hosted anywhere. Build & run locally with hot reloads. Customizable colors, layouts and theming.
What we don't like: The philosophy is based on everything being public, which might not suit how you want to take notes. Quartz supports private pages, but it requires additional config.
What we like: Graphical TUI for executing HTTP requests. Keyboard-first navigation. Request collections stored in local files for easy sharing, versioning, issuing common requests. Supports environment variables for dynamic configuration e.g. changing URLs. Quick access command palette. Can import OpenAPI specs.
What we don't like: Installed as a Python package rather than a static binary.
What we like: JS component that can be embedded in any web application. Zero dependencies. Customizable using HTML & CSS since it’s all just JS. Define your own commands with custom functions. Can be automated to provide realistic demos or animations of terminal UIs.
What we don't like: It’s just the terminal frontend - if you want to use it as a “real” terminal then you’ll need to write your own connection logic for SSH, bash, etc.
What we like: Define jobs and workflows in Go which gives you all the functionality of Go e.g. types, calling functions, defining retries in code, etc. Transactional enqueuing helps avoid edge case failures. Queue management with error handling, scheduled jobs, snoozing jobs. Clients can subscribe to events using Go channels. Includes a management UI.
What we don't like: Primarily built in Go, although there are official clients for Python and Ruby. Relies on Postgres (which may be a good thing if you already use it and don’t need the performance of something like Redis).
What we like: Hooks into BPF syscalls to collect runtime stats every second. Shows runtime, events per second, CPU utilization of all running eBPF programs. Real time tabular view. Metrics can also be graphed. Collects stats only whilst running to minimize the performance impact.
What we don't like: Dynamically linked to several libraries (libz & libelf) which are required for it to run.
What we like: Reads in environment variable files. Runs as a CLI rather than a library so it works with any language. Supports encrypted key values so the environment variable file can be committed to Git. CLI also supports other commands e.g. get and set. Open source and works across platforms.
What we don't like: Environment variables are great for configs, but not the right place for secrets.
What we like: Supports synthetic API monitoring and real user monitoring with an embedded JS snippet. Monitors can be made public for status transparency. Users can subscribe to status pages. Supports alerting and notifications of issues via Discord, Slack, SMS, PagerDuty. Open source - self-host or use their cloud service.
What we don't like: No docs for how to self-host other than running the dev environment locally.
What we like: Reconfigures Ubuntu 24.04 with a more visually appealing and functional UI. Consistent themes across applications including terminal, browser, code editor, backgrounds. Installs common applications e.g. Alacritty, Docker, GitHub CLI. Sets up proper font configs. Includes a UI for configuring everything.
What we don't like: Opinionated, but with some flexibility. Obviously only works on Ubuntu.
What we like: Terminal uses an actual text input field so you can use normal shortcuts. AI agent mode can take multi-step actions based on natural language requests. Proposes commands before executing them. Reviews output so the next command/step is based on the real results. Can learn CLIs based on help output. Command search (history, workflows, notebooks).
What we don't like: No Windows version.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Build web app functionality by using augmented HTML attributes rather than complex JS frameworks. Supports HTTP requests, WebSockets, server sent events, CSS transitions, etc all in HTML. No dependencies. Has built in form validation. Events system linked to logging for debugging. Open source.
What we don't like: Logic is defined directly in the DOM which poses a security risk - you need to properly think through escaping and whether to use certain attributes. Setting a CSP is particularly important.
What we like: Define multi-step sync & async workflows and tasks in code and have them executed. Durable against failures with granular step by step retries. Sleep & suspend code for arbitrary lengths of time (even months). Single (Rust) binary which can be deployed on k8s or AWS (EC2, Lambda). Open source and cloud service.
What we don't like: Currently only supports writing workflows in TS, Java, Kotlin.
What we like: Optimized searches for developers based on known tech stack and tool integrations e.g. GitHub. Choose whether to use on-device only or cloud augmented LLM searches. Standalone desktop app and IDE integrations. Can optionally scan workflows in other apps e.g. discussions in chat, web browsing, to add context to searches.
What we don't like: Non-native app (Electron), but that does mean it is cross-platform.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: CLI for managing app deploys. Can be as simple as pushing to Git which triggers a build & deploy. Uses runtime specific virtual environments e.g. virtualenv for Python, separate GOPATH for Go. Uses a Procfile to manage multiple processes. Configure environment variables, virtual hosts, and SSL. Works cross-platform. Really small codebase so it’s easy to understand.
What we don't like: Requires Python on the deploying host rather than being built as a static binary. Doesn’t support everything - currently Python, Node, Clojure, Java, Go, Ruby.
What we like: Anonymizes data based on analyzing the source. Generates realistic synthetic data based on your schema. Configurable mapping and transformation to control how data is represented in the anonymized / synthesized form. Can provide representative subsets of real data for use in test rather than needing a full copy of the huge prod database. Open source so can be run independently.
What we don't like: Needs more database support - currently Postgres, MySQL, MongoDB. Large cloud warehouses like BigQuery or ClickHouse are missing.
What we like: No background worker needed - it’s a Postgres extension that bundles functions. Supports exactly once delivery. API compatibility with AWS SQS. Each queue is its own table. Messages can be archived for long term retention. Supports partitioned queues.
What we don't like: Be sure to understand the visibility timeout to ensure exactly once delivery operates as expected. Only has official clients for Rust & Python.
What we like: Based on default browser styling, but easy to customize. Provides good looking defaults. Lightweight, no build step, can be reduced by excluding unused elements. Covers a wide range of HTML elements. Includes syntax highlighting classes. Dark mode support. Tea-based name.
What we don't like: Missing some utility classes for setting common options in shorthand.
What we like: Live dashboard with views based on GitHub filters - show PRs & issues. Customizable columns, keybinding actions, refresh interval. Themable. Can perform basic actions e.g. comment, assign, merge. Extension built on top of the gh CLI so you don’t need extra creds. Watch issues to get notifications on check completion.
What we don't like: Search initially says there are no results whilst search is in progress - it sometimes takes a few seconds during which time it looks like there are no results.
What we like: Simple API to issue search queries to LLMs from code: exa.search(“query here”). Can auto-suggest prompt changes to optimize searches e.g. keyword searches don’t work well with LLMs. Avoids the need for prompt chaining. Has specialist indexes for things like companies, GitHub repos, papers, blogs, jobs.
What we don't like: SDKs limited to Python, Go, Node.
What we like: Supports logs, traces, and metrics using custom SDKs or OpenTelemetry. Parses JSON logs for structured queries. Also supports session reply and error reporting. Uses ClickHouse as the storage layer. Create custom data visualizations. Includes alerting via email, Slack, PagerDuty.
What we don't like: Limited official SDKs (browser, Node, Python) which means you need to rely on Otel for other platforms, each with varying feature support.
What we like: Set up a .tool-versions file in your repo and the asdf CLI manages all the runtimes scoped to that directory. Handles things like Node.js, Ruby, Elixir runtimes. Allows you to have multiple runtime versions for different projects and manage how they are updated.
What we don't like: There aren’t many official plugins, so you have to rely on community plugins.
What we like: Browse files from the terminal. Pin folders and navigate visually. Configurable keyboard shortcuts for moving around, spawning multiple panels and performing actions like rename, copy, delete. Includes a clipboard manager. Inspect file details. Themeable. Available in package managers and as a single binary.
What we don't like: Windows is not fully supported.
What we like: Jira/GitHub alternative with issue tracking, project boards, and milestones. Includes pages/wiki functionality and file hosting drive for attachments. Optional inbox functionality for managing requests. You can sync issues to GitHub. Open source and can be self-hosted using Docker or k8s.
What we don't like: Integrations e.g. GitHub Issues sync are not open source and aren’t available on self-hosted.
What we like: Analyzes PRs and adds LLM-generated reviews. Includes a high-level summary, per file summary, and specific-line comments where appropriate. Can respond to follow up questions in-line within the PR. Considers the context of linked issues to evaluate whether they are solved by the PR. Configurable via a YAML file.
What we don't like: Requires GitHub or GitLab. Doesn't provide review comments for code formatting related changes - you probably need a linter as well.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Shell scripting with an interactive shell. Distributed as a static (Go) binary so works on (and can easily be shipped to) lots of platforms. Shell shows errors before execution e.g. undefined variables to avoid unexpected behavior. Built-in searchable directory and command history. Also has a file manager UI.
What we don't like: It’s pre-v1.0 so there may be breaking changes.
What we like: Browser extension development framework. Allows you to write extensions for most browsers using TypeScript / JS, React and CSS. Supports calling into WebAssembly. Dev command supports live reload. Helps build & package for distribution.
What we don't like: No support for Safari or mobile browsers like Firefox for Android & Safari on iOS.
What we like: Wraps around Nix to provide declarative developer environments. Automatically activates environments when entering the directory. Manages scripts, Git hooks, running services, containers. Supports tests & process management. Environments per directory can be imported into a main environment in monorepos.
What we don't like: Doesn’t support building containers on macOS - must connect to a remote Linux builder.
What we like: Create composable pipelines of tasks and process them. Run tasks in series and/or parallel to break complex flows into multiple pipelines. Supports file watching to run workflows as things change. It’s a framework on top of JS so you get the full power of JS - process execution, calling APIs, other modules, etc. Open source.
What we don't like: Upgrade from v4 to v5 changed default stream encoding to UTF-8 which can break some binary file transformations when using incorrect encoding configs.
What we like: Easily define & execute HTTP requests in plain text. Chain requests, evaluate queries, define assertions. Built-in manipulation tools for HTML, JSON, REST, SOAP, GraphQL. Export reports for response time monitoring. Supports request templates & variable injection. Open source.
What we don't like: Focused on being a CLI tool so it has no GUI - great for its purpose, but if you want a GUI then other tools are more appropriate.
What we like: Consumer & B2B SaaS auth APIs, with separation of top-level org as a unit of multi-tenancy. This allows different configs & users per org within the same top-level project. Supports social auth, magic links, passkeys, SSO, SCIM. Also includes RBAC permissions. Customizable JWT claims. Management UI has dark mode.
What we don't like: Device fingerprinting features aren’t available self-service. Missing some popular language SDKs e.g. PHP, Rust, .NET.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Caches calls to NPM which makes resetting Node projects much faster on subsequent downloads. Particularly good for containerized applications where you regularly prune containers for a fresh dev environment. Runs as a lightweight container. Can override public packages.
What we don't like: Need to be careful how you specify the private registry otherwise it will be written to the package lock and break remote builds/deploys.
What we like: Generates idiomatic Go code based on your database schema and desired queries. Translates SQL to type-safe Go code. Interface to the generated code feels like proper Go. Can run static analysis on schema changes to detect breaking changes across the codebase. Useful tools to help ensure codegen is up to date and highlights SQL anti-patterns. Open source.
What we don't like: No support for cloud databases like BigQuery or ClickHouse (there is currently a waitlist). Primarily supports Go, but has some experimental plugins for Python and TypeScript.
What we like: Builds Docker images in the cloud rather than on your local machine. Links to Docker Desktop & CLI for transparent usage. Shared cache within a team speeds up builds for all users. Managed multi-arch builders for AMD & ARM platforms. Smart layer caching only builds what’s changed. Also integrates with CI.
What we don't like: Currently only running in US East so if you transfer lots of files in the build steps, latency and bandwidth can become a bottleneck. More regions on the roadmap. No web UI for managing what’s in the cache - can purge from the CLI.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Use any runtime - Node, Bun, Cloudflare Workers, Vercel, Lambda, etc - with a (mostly) consistent API abstraction. Zero dependencies. Uses the Web Standard API. Supports sophisticated routing configurations, middleware, client components, validation, RPC. Includes a testing framework.
What we don't like: Environment variables can’t be accessed outside of the handler. Some features are limited by the runtime e.g. WebSockets only work on Cloudflare, Bun & Deno.
What we like: Build tasks and workflows in code (currently Python, Go, TS). Each stage of a workflow is independent and can be run durably and retried without losing progress so far. Run your own workers so you control underlying resources, location, and data privacy. Manage concurrency and rate limiting of steps to control resource consumption. Cloud service, but you can also run the control plane yourself.
What we don't like: Is Postgres appropriate for a distributed task queue? Seems to be, and it’s likely already part of your stack (or you’re using a managed service).
What we like: Flexible approach to building authorization logic with a DSL. No need to rely on a single centralized service - centralize the logic, which can return “yes, if” for validation with local data. Makes it easier to reason about complex auth across microservices. SDKs for Node, Python, Go, Ruby, and .NET. Check in your auth .polar files to Git.
What we don't like: Default model uses Oso Cloud, but there are options for self-hosting and running a hybrid cache layer for HA.
What we like: Creates & manages virtual environments and installs packages into them. Makes it easy to manage devtools, libraries, runtimes without conflicts. Handles dependency management for any installed packages. Easy to share environments with other people. Environments can be defined declaratively in a config file.
What we don't like: Uses Nix behind the scenes which is both great (declarative language for package management), but also quite complex to understand if you want to build your own packages.
What we like: Visual, browser-based editor for designing database schemas. Supports MySQL, PostgreSQL, SQLite, MariaDB, SQL Server, plus object relational databases with JSON schemas. Create templates for common designs. Export the results to SQL to actually create the database from your work. Free, open source, you can host it yourself.
What we don't like: Limited import support for existing databases - currently only from MySQL.
What we like: Single (Rust) binary for managing dotfiles. Works cross-platform with OS specific config options. Sync across machines with Git. Supports yaml, toml, or json config files. You can create files from templates using the Handlebars syntax. Configs can have dependencies before they are installed. Open source.
What we don't like: Relies on the system-installed Git. Supports distinction between OSs, but not distros within OSs e.g. commands for different Linux distros.
What we like: Generates API docs from your OpenAPI/Swagger file. Runs through an LLM to also generate detailed guides alongside the reference. Design can be customized with access to CSS variables. Includes an editor for real-time collaboration on the generated output. The generator and the output are open source, so you can self-host or use their hosted docs service.
What we don't like: No support for other types of APIs e.g. gRPC & Protobuf.
What we like: Simplifies publishing workflows for npm packages. Performs lots of useful checks like checking for the release branch, clean working directory, running tests, etc. Handles version bumps, GitHub releases, packaging, tagging. Includes 2FA. Handles rollbacks in case of failure.
What we don't like: Doesn’t support monorepos. Designed as an interactive CLI rather than as part of an automated workflow e.g. in CI.
What we like: Scale Postgres horizontally by configuring shards. Wire protocol compatible so all existing clients work - they don’t need to be shard aware. Includes connection pooler so you can replace PgBouncer et al. Can run multiple routers for HA. Live config reloading.
What we don't like: Doesn’t support cross-shard queries. Docs are limited - no quick start guide, but browsing the example configs gives you an idea of how to get going.
What we like: 3.0 release includes new layout components (box, flex, grid, section, container), new colors, and new components (skeleton, spinner, etc). Type safe via component props rather than utility classes e.g. as in Tailwind. Radix is a multi-layer framework so you can always get at the unstyled React primitives, icons, and colors.
What we don't like: This is a component library so you don’t get pre-built app/site layouts. Components don’t give easy customization options because they’re designed to fit into themes/color palettes, but you can get access to the CSS variables to create custom components.
What we like: Makes it easy to build sophisticated text editing features like undo, real-time collaboration, history tracking & versioning, and conflict resolution of multiple edits. Available as a Rust library as well as a JS package which uses WASM. Allows offline editing.
What we don't like: API is not yet stable so they don’t recommend using it in production.
What we like: Drop-in web UI for managing and observing Kafka clusters, topics, connectors, consumer offsets, etc. Easily edit & reprocess messages. Graphing and alerting on topics & partitions. Cluster managers can set up self-service for developers with different environments. Proxy gateway enables ACLs, RBAC, auditing, encryption, masking, load balancing.
What we don't like: You need to manage the console and gateway deployments by running the Conduktor container somewhere - no easy managed service.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Download a URL to a single HTML bundle. Embeds all the assets into the file so it can be loaded offline (or more likely, when those resources disappear or change). Options to exclude assets like videos and audio. Can block domains e.g. to block ads or other included resources. Single binary CLI.
What we don't like: Requires a preprocessor if you want to save pages which use JS to load data after the initial page load.
What we like: Underlying platform for running containers (with Podman Desktop as a GUI). Now supports the latest macOS VM framework. Pasta networking backend now the default allowing rootless / unprivileged connectivity. Supports various OCI formats for running various containers. Simplifies k8s locally.
What we don't like: You may need to migrate to the new format if you were using the previous machines functionality.
What we like: Easily interact with APIs - manipulate requests, params, response. Build collections with different environments which are stored in a plain text markup language locally. Supports reading secrets. Includes scripting support for complex API interactions. Also has a CLI.
What we don't like: No sync of collections is a deliberate philosophy vs alternatives which makes collaboration harder, although you can just sync them via Git.
What we like: S3 compatible API so all your existing S3 tooling works as a drop-in. Key differentiator is the auto-migration & caching of objects to the region where they’re most used. Fixed pricing globally and no internet ingress or egress fees. Buckets are private by default (supports signed URLs), but can be public.
What we don't like: It’s built on and integrated with Fly, but has no visibility in the Fly web dashboard (only the CLI). Tigris has its own rudimentary web UI, but this really is a CLI/API first initial release.
What we like: Well designed native macOS app focused on Git diffs. Easily compare files and branches. Visual commit
What we don't like: macOS only. Does not support custom syntax highlighting themes.
What we like: Modern, open source package registry for JS/TS modules. ESM-only. Supports multiple package managers inc. npm, yarn, pnpm, Bun, Deno. Secure publishing workflows by default. Auto API doc generation and scoring to encourage best practices. Open source.
What we don't like: Requires a compatibility layer for npm. Forces you to use TypeScript and ESM, but it’s 2024 so this is also something we like!
What we like: Continually runs in the background, watching Rust files for warnings or errors. Also runs tests. Sits in your terminal. Configurable commands and watch directories. Supports .gitignore. Can run multiple instances e.g. for different build targets. Nvim plugin available. Open source.
What we don't like: Has some overlap with what you may already have in your editor e.g. rust-analyzer in VS Code.
What we like: CLI to export data from one source database and load it into another. Lots of different sources & destinations e.g. Postgres to DuckDB, SQLite to BigQuery, etc. Supports various incremental loading strategies - append, merge, delete+insert.
What we don't like: Requires specifying the source and destination tables - doesn’t copy the whole database schema.
What we like: Lots of integrations for ingesting alert triggers. Built-in notifications for email, SMS, phone, mobile app. On-call management, scheduling, escalations. In-bound phone option to route to on-call responder. Slack & Teams ChatOps. Create hosted status pages with custom domains.
What we don't like: Status page can be set to dark mode, but the main UI cannot.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Easily access core Git commands via an interactive terminal interface. Supports most common commands with keybindings to quickly work through tasks. Inspired by Magit.
What we don't like: Still early in development, but has common commands implemented. Needs to be installed via Rust’s cargo - no packages yet.
What we like: Integrates with Git, Tmux, and your editor to manage the project file tree. Preview files with syntax highlighting, file fuzzy search, run commands across the project, explore the files with support for show/hide hidden files and .gitignore. Keybindings and custom command support.
What we don't like: Sections can’t be configured. Hasn’t had a release for a while.
What we like: Minimal setup required to get detailed cost reports. Breakdowns by service, account, environment, resource. Segment by team and calculate unit costs. Anomaly detection and notifications e.g. weekly Slack reports. Autopilot auto buys, applies, sells reservations to optimize spend. Terraform provider.
What we don't like: Would like to see additional integrations for other cloud services. Initial data load can take some time if you have a lot of accounts.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Vendor executables without checking large binaries into source control. Makes it easy to standardize & pin specific dependency versions e.g. Node or an internal-only runtime build. Downloads and verifies the binaries. Can be generated using the included GitHub Actions workflow.
What we don't like: It’s not a package manager and is designed for a single binary. The main limitation of this is the lack of support for installing dependent packages.
What we like: Make text edits across many files in one go. Can be connected to fzf and a highlighter/pager to show the edits visually. Previews the changes by default so you can verify. Or pass a commit flag to make the changes right away. Supports regex replacements.
What we don't like: Requires some additional tools like fzf and a highlighter to improve the UX, but this is really just the Unix philosophy of doing one thing well and deferring to other tools for the rest!
What we like: Serverless access to GPUs for training and inference. Support for pipelining to allow transcriptions & encoding. Access to the latest LLMs and LoRA for fine-tuning. Supports parallel execution, cron jobs, queues. SDK allows easy switching between local and remote calls.
What we don't like: The SDK is Python only. 1s cold start, but you can warm up containers ready to serve traffic.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Colorizes and highlights various common log formats. Can combine multiple (large) log files. Keybindings for jumping around and triggering search. Search supports regex. Can also tail.
What we don't like: Only available through pip rather than as a compiled binary or via OS packages. Doesn’t work on Windows.
What we like: Introduces concept of virtual branches which work off base and allow simultaneous changesets which can be committed & pushed separately, even in the same file. GUI makes it easy to understand and allows drag & drop of changes to other branches.
What we don't like: You can’t use git branches and virtual branches at the same time - you need to pick one.
What we like: Set of common components for email templates e.g. tables, headings, images, code. Can render Markdown. Components work across all major email clients. Local preview web UI for live development. Supports Tailwind for customization. Can convert existing React components.
What we don't like: VSCode integration and MDX support are on the roadmap.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Lightweight library to benchmark TypeScript applications. Supports before & after hooks across tasks and globally. Reports stats for each run e.g. min, max, percentiles. Supports listeners on events. Open source.
What we don't like: Doesn’t do anything with the results by default - don’t forget to log or store them somewhere.
What we like: Nice enhancement to the ping command - adds a graph. Alternative cmd flag to measure the execution time of arbitrary commands. Customizable colors. Available from a range of package repos and as a single binary.
What we don't like: Nothing really - it’s a very simple tool.
What we like: Easily implement a globally distributed event gateway without worrying about scaling and redundancy. Direct incoming events to arbitrary destinations. Visual console to inspect requests and results. Options to throttle, transform, filter, delay, and replay event processing. CLI for local development. Pause event processing for maintenance and backfill later.
What we don't like: Rate limit to destination is only configurable as a simple limit per period e.g. 10 per second, with no advanced options.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Create your own private network for all your devices, servers, environments. Simplify SSH login with auto managed keys linked to your identity provider. Define network rules for who can access what. Access private resources without opening firewalls. Connect ephemeral CI workflows to your network for access to resources e.g. test databases. Clients for all platforms.
What we don't like: Web UI has no dark mode. Configuring tags and ACLs can be confusing and difficult to debug.
What we like: Markdown-like so it’s not something brand new to learn. Built-in headless components like tables, buttons, videos, layout grids. Separates content from design and based around web components. Avoids MDX mixing complex imports and JS. Minimalist progressively enhanced content-first philosophy.
What we don't like: Primarily designed to work with bun, but will also work with pure Node if you prefer. This means access to the full React/TS/JS ecosystem is more limited
What we like: Define secrets in one place and sync them everywhere they’re consumed. Supports different environments for prod, staging, prod, etc. Track versions and change history. Automated rotation for common services e.g. AWS, GCP, Twilio. IDE integration and CLI for launching processes with secrets injected into the environment. Cached for offline use.
What we don't like: CLI works on Windows, but if you’re not using WSL it requires some additional setup. Limited SDKs for retrieving secrets in-code (you have to use the CLI instead).
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Block-based text editor designed for developers - like buffers in other editors. Global hotkey to show/hide. Code is auto-detected, syntax highlighted and auto-formatted. Blocks can run calculations e.g. unit or currency conversions. Runs on macOS, Linux & Windows.
What we don't like: Built with Electron. You can’t really tell, but how does it perform with lots of blocks…?
What we like: Write functions in any language that can be compiled to WASM e.g. Go, Rust, Zig. Tarmac adds platform features like callbacks, logging, k/v store, SQL and HTTP fetching. Functions get exported to WASM then deployed using Tarmac running as a container (or outside of Docker if you prefer). Chain together functions into services.
What we don't like: Official SDK only available for Go (using TinyGo), but you can call out into Tarmac platform primitives from other languages.
What we like: CLI for quickly creating standardized commits in conventional commit format. Define config in a repo JSON file e.g. to define formats and scopes. Can infer types and issue numbers from branches. Colorful interface. Emoji can be used, but also disabled.
What we don't like: Long default CLI name so you’ll want to create an alias.
What we like: Simple route definition with handlers that accept params, request methods, catch all, or more complex route rules. Includes middleware support, a storage layer for abstracting data storage, and a cache API. Handles static assets. It powers the Nuxt framework so is proven in production. Deployment adapters for Edge, Node, Bun, Deno, and lots of platforms.
What we don't like: Great for full stack web applications, but JS is probably not the best choice for a web server in performance-sensitive scenarios.
What we like: Visual representation of how your Rust code is executing with a full call tree. Capture all parameters and return values for all functions. Makes it easier to trace errors through Results so you don’t lose the context of the error. Only traces user code avoiding getting bogged down in libraries.
What we don't like: Only works if you are using Cargo Workspaces. No async Rust support.
What we like: CLI to deploy any containerized app to any server (VM, bare metal, etc). Works with a single or many servers. Handles rolling deploys with health checks. Includes Traefik to proxy traffic to the container. Supports persistence e.g. for databases and volumes. Much simpler than figuring out k8s.
What we don't like: Logs into servers directly (or via a proxy/gateway) over SSH, which means you still need to deal with connection security. You also need to maintain the server OS, unlike a managed k8s where your focus is the container.
What we like: True drop-in replacement for grep - it focuses on the UX to make it easier to search. This means an interactive TUI by default. Lots of small UX tweaks vs GNU grep e.g. matching unicode by default, can search archives like .zip, can search PDFs, docs, and other file formats. Different outputs e.g. JSON, XML.
What we don't like: Not much to dislike! It’s written in C++ rather than Rust, which some might consider vs something like ripgrep, but is that really an issue?
What we like: CLI & GUI to make submitting stacked Pull Requests easy. Auto-restack makes rebasing main into multiple branches a single command. Submit PRs and request reviews from the CLI. Trigger the merge queue from a GitHub tag which handles rebasing, status checks, and then merging sequential PRs with no interaction.
What we don't like: Shifting into a trunk-based model is quite a shift in mindset if you’re not used to a single PR per commit. GitHub only.
Interesting Tools by email
Our free weekly newsletter picks out the 2-3 most interesting tools. See the latest email