Console
Developer tools reviews
Each week Console reviews the best tools for developers.
✦ Disclosure: All reviews are editorially independent and partners must meet our selection criteria.
Category reviews
Interesting Tools by email
Our free weekly newsletter picks out the 2-3 most interesting tools. See the latest email.
Join 18k+ developers
What we like: Go binary or run as a container (includes official Helm chart). Resize images via URLs, which can (and should) be signed. Can serve files from cloud storage (S3, GCS, etc). Can compress, crop, fill, blur, watermark and convert to desired formats. Emits metrics to Prometheus, New Relic & Datadog. Open source or cloud service.
What we don't like: Designed to focus just on image resizing - you need to configure your own caching and HTTPS proxy, and other non-core features - but this is a deliberate tradeoff for security & performance. No official images for Windows or arm64.
What we like: Designed to work particularly well for use cases with lots of similar files that don’t change often. Snapshot command stores the state of the current working directory - execute as you make changes like a git commit. Pack command compresses the snapshots. Very fast snapshot extract. Open source and works on Windows, Linux, macOS.
What we don't like: Snapshot names have restricted allowed characters e.g. period is not allowed which would be useful for version numbering. Pre-compiled binaries Linux-only so you need to build yourself with Rust.
What we like: Work with field names rather than positional indices. Add new fields, run aggregations, colorized, tabular pretty-print. Operates with streams so only a single record is in memory at one time (unless needed for certain operations like sort) i.e. minimal footprint. Single binary (Golang, open source) with packages for Windows, Linux, macOS.
What we don't like: Uses its own color scheme rather than inheriting current shell profile. Lots of power in the Miller DSL and the built-in command verbs can do a lot, but it’s another programming language to use for custom transformations.
What we like: Docs live as Markdown in the code repo. Smart editor links snippets and references even through refactors, moves, renames, etc. Plugin for VS Code and JetBrains editors to render docs in-line/. Integrate with CI (or Git hooks) to get PR comments and a quick edit link when docs need updating.
What we don't like: CLI can be run in any CI/CD environment, but the GitHub app gives much faster feedback as PR comments (other integrations on the roadmap). Any existing docs need to be imported manually.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Provides an HTTP API with caching, pre-aggregation and SQL support on top of popular datastores e.g. Postgres, Redshift, BigQuery. Visualization libraries provided for D3, Vue, Angular, React. Local “playground” UI makes it easy to debug queries. Open source (including cluster mode for scaling). Optional cloud version.
What we don't like: Caching can’t be disabled and requires Redis in prod, but the refresh time can be set to a low value e.g. 1s. SQL and GraphQL APIs still in preview.
What we like: Simply watch files and execute commands when changes are detected. Specify files, filetypes, directories, filters/ignores (including .gitignore). Can issue command restarts e.g. for servers. Runs commands in a shell, which can be specified (or set to no shell).
What we don't like: Directory watch is recursive, which might catch a large number of files (filter can be used to ignore them).
What we like: Snapshots allow you to visualize changes in cloud resources. Provides security and compliance suggestions, which can be exported to CSV. Search and filter resources which are highlighted in the map view. Provides a GraphQL API for your cloud resources. Open source backend with CLI.
What we don't like: Can’t define custom policies for flagged issues. Auto crawl is only triggered once per day (can be integrated into CI/CD to trigger a version on deploy).
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Manages WIP branches and makes it easy to hand over development to your programming partner(s). Makes it easy for multiple people to simultaneously contribute to a coding session. Built-in timers. Squashes commits by default. Single binary CLI with packages for macOS, Windows, Linux (including Arch & Nix).
What we don't like: Config options set via environment variables only, so cannot be persisted across sessions. Default timer notification uses the system voice to speak out loud - can be changed via config, but a nicer media bell sound might be better.
What we like: Gradual install so you can slowly roll it out to different parts of your repo. Pipelines defined in package.json. Caches based on hashes so builds are incremental, which also includes logs and emitted files, making builds much faster. Supports remote caching that can be shared using content addressable storage.
What we don't like: Treating logs as artifacts and caching them + emitted files is a technique which needs highlighting. Developers are careful about what gets output e.g. environmental variables and sensitive data in build logs.
What we like: Simple CLI for automating testing for memory leaks, primarily relevant for SPAs. Examines objects, event listeners, DOM nodes and collections. Default test scenario does most of what you need, but custom scenarios can be defined e.g. custom setup to log into an app. Has an API.
What we don't like: Sensitive to all memory growth, a small amount of which may be perfectly normal for maintaining state. Focuses on the main frame so ignores cross-origin iFrames or web workers. Chrome-only.
What we like: Commits uncommitted changes every 5 sec to a separate branch without affecting HEAD, the current branch or staged files. Use standard git commands to switch to the Dura branch if you need to recover. Can watch multiple directories.
What we don't like: Still a prototype. Recovery requires multiple git commands to manage your working directory and checkout the branch. No indication whether the background process is still working.
What we like: Not as fiddly as curl - can use shorthand URLs and it’ll do the right thing (HTTPS by default if using xhs binary). Can ask it to output the curl equivalent command if needed. Easy to specify body parameters, query strings, set request headers, get response headers. Response colorized by default. Packages for most systems (Mac, Linux & Windows).
What we don't like: Doesn’t use the system TLS library, which means more consistent results but could cause issues if using it to troubleshoot local issues. No support for HTTP/3.
What we like: RBAC for remote login to servers (SSH), databases, k8s, desktops and internal web applications. Uses cert-based access control with 2FA rather than passwords or keys. Records all sessions automatically. Teleport SSH server compatible with OpenSSH so you can use any client (including a web client). Open source - deploy self-hosted or via cloud.
What we don't like: Supports config via Terraform but the provider is not available in the Terraform registry - must be installed manually. Desktop access for Windows only (for now).
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Use regex syntax from JS and Python rather than figuring out sed and awk. Find and replace using string-literals to avoid regex entirely. Simple syntax for in-file operations, including preview changes. Simple replacements on large files significantly faster than sed. Cross-platform support with packages for common OSs.
What we don't like: Latest release missing Windows binary (included with previous versions). Release binaries on GitHub only provided for x86, but other options included in OS packages.
What we like: Sits on top of S3-compatible object storage and acts as a copy-on-write management layer/proxy. Create branches of data e.g. to run tests, upgrade tools, migrate schemas, etc without risking the data. Atomic merge avoids bad states and allows rollbacks. Can ingest existing data without copying it.
What we don't like: Depends on PostgreSQL for storing metadata, which adds operational overhead (decoupling, pluggable interfaces and storing metadata in the object storage itself are all on the roadmap).
What we like: Auto-suggests initial tests. Config and tests are code. Either run as a CLI with all analysis done locally, or as a Python library to programmatically test data. Configurable expected error rate before erroring. Works alongside Airflow, Dagster, or dbt to support scheduled tests. Open source - cloud service optional (alerts and reporting).
What we don't like: Initial installation and setup varies in complexity depending on your datastore. No colorized output from the CLI. No other language SDKs.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Easy to create a replicated (sync or async) in-memory cache across distributed nodes. Can be used as a client/server (language independent & horizontally scalable) or as an embedded Go library (lower latency). Supports topics and listeners for distributed event processing.
What we don't like: No persistence. Binary protocol currently undocumented and Go is the only supported client.
What we like: Dependency free - lightweight total size. Everyone needs a datepicker eventually and the UX is always difficult to get right. Support for all major browsers going back to very old versions. Date, time, date range selection. Libraries for React, Vue, etc. Supports localization and themes, including a dark version.
What we don't like: Browser built-in alternatives are improving quickly, which offer a more native experience with better accessibility, but not as good functionality. No release since Dec 2020.
What we like: Makes terminal cheat sheets from tldr available offline (cached) with common examples for how to use the specified command. Colorized output uses your shell color preferences. Open source, cross platform and packages available for most systems.
What we don't like: Latest release is >1 year ago which is missing many fixes and updates made to the project since.
What we like: Designed to be invoked via client libraries so the test conditions can be deterministic and programmatically defined. Simulate latency, timeouts, peer resets and other weird network conditions. Can be configured to introduce randomness. Official clients for Ruby and Go (other community clients available)
What we don't like: Requires connection through a client rather than dropping into the middle of the connection with no code changes (but this is what enables the programmatic testing).
What we like: Markdown-based editor with custom dev-docs focused components e.g. diagrams, multi-language code blocks, GraphQL / OpenAPI endpoint blocks, changelogs. Build internal or public docs. Publish multiple doc versions e.g. for different API versions.
What we don't like: No real-time collaboration - edits by others overwrite your changes. Sync to GitHub allows Markdown source to live in the repo, but editing is much more limited.
What we like: Define rules and automations in code based on conditions for approvals, assignment, merges, rebasing, reviews, queueing and prioritization. Can examine attributes like task list status, PR dependencies, Dependabot, Snyk and other tool integrations. Engine is open source.
What we don't like: GitHub only. Specifying PR dependencies does not work across repos.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Code samples can run locally in the browser (using WebAssembly). Can be embedded into a web page using an iFrame or web component. Enable editor to allow the user to modify and run the code. Sandboxed and runs in a terminal emulator.
What we don't like: Limited by language runtimes available in WebAssembly Package Manager - Python, JS, SQL, C, C++. Best for simple code that uses stdin / stdout.
What we like: Lots of plugins for sources e.g. AWS S3, Apache, StatsD, stdin; transforms e.g. aggregate, filter, log to metric; sinks e.g. Cloudwatch, Prometheus, Elasticsearch. Makes it easy to create a consistent pipeline even as sources and sinks change - no lockin. Can run as a single agent, sidecar or as an aggregator cluster for more throughput. Open source.
What we don't like: Transforms performed using the custom Vector Remap Language, which is another syntax to learn (but does compile to Rust = safety + performance).
What we like: Manage your packages across all repos from a single service (RPM, Deb, RubyGem, PyPI, NPM). Web UI or CLI to push new packages. Create private repos for internal packages. Auto-generates install scripts for users. Integration with CI to easily push packages on build.
What we don't like: Quick installer instructions and package inspection (view files, dependencies, etc) not available for all package types. Would like to see support for container repos.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Project-based and sandboxed, which makes it safer to use it to try third-party projects. Config is code (Starlark) - no arbitrary flags, env vars, etc, so the result is much more predictable. Inputs/outputs are content addressed, hashed and cached (or built from source) which then makes them reproducible.
What we don't like: Currently a proof of concept, only works on Linux (macOS soon). Defining the full dependency tree can be tedious, but that is the whole point of sandboxing and ensuring reproducible builds.
What we like: Quickly show possible performance problems in your HTML <head> such as blocking JS, redundant calls, third-party stylesheets. Either drop in a CSS stylesheet or run the JS snippet for any page using browser devtools.
What we don't like: Prone to some false positives, e.g. non-blocking non-print stylesheets, injected JS, whether the third-party JS is truly non-blocking. Unknown license.
What we like: Use GraphQL to query resources. Queries run against a cached database which you can scale yourself, avoiding AWS limits. Consistent interface across products - avoid complex JOINs. Query historical state because data is versioned. Bundled UI with autocompletion and schema explorer.
What we don't like: Currently only supports AWS. Deployment is currently manual (or via Docker). Docs are still quite limited.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Quickly search and filter system and user units. State view shows service metadata plus recent logs. Shortcuts for filtering by state and reloading. Prompts to run relevant commands.
What we don't like: Requires fzf, which must be installed manually. Assumes you know what you’re doing, but since it’s Linux-only, you probably do.
What we like: Significantly speed up common git tasks with shortcuts. Improved version control view with show/hide diff, easily stage individual files or multi-select changes. Stage chunks of changes. Forge mode provides extra context from GitHub e.g. issues, PRs.
What we don't like: Forge mode slows down status view initial load. Doesn’t yet support the more advanced features from Magit (advanced diff, bisect, patch).
What we like: Displays real-time stats as tests are executed, both on the CLI and via a web UI. Reports latency, req/s, errors, read/writes. Includes latency histogram and percentiles. Supports all HTTP verbs including reading in POST data from a file. Dockerfile provided.
What we don't like: Histogram charts disappear and web UI stops serving on test completion.
What we like: Runs a full version of SQLite entirely in the browser. Can load DB files from a URL or a file. Can optionally sync with GitHub to save data and queries in plain text. Easy to share via a link. There is no server. Open source.
What we don't like: No code completion. No error handling UI (check the browser console).
What we like: Implements automated delivery from Git to k8s. “giterminism” concept provides reproducibility without external config dependencies - everything is based on the git repo. Handles Docker image builds, k8s rollout and cleanup. Can be embedded in existing CI/CD pipelines. Generates and manages Helm templates.
What we don't like: Needs expanded guides for languages - basics are covered but missing more detailed real-world examples. Assumes you’re running on k8s.
What we like: Automate tedious incident handling workflows e.g. create new Slack room, status page update, create Zoom bridge. Inventory catalog assigns teams and aggregates useful tools (e.g. PagerDuty on call, Datadog dashboard, last GitHub event) for quick lookup during incidents. Auto-generate timelines based on chat logs, events, actions to make retrospectives easier.
What we don't like: Small number of integrations e.g. assumes using Slack for chat, JIRA for tickets, Zoom/Meet for conferencing.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Record and debug user sessions with full devtool capture (JS errors, network, perf, state). Sanitize data before it is captured through generic global rules or HTML attributes. Can un-minify JS with source maps. Plugins to capture API requests e.g. GraphQL and correlate with backend monitoring (Datadog, New Relic, Cloudwatch, etc).
What we don't like: Limited documentation for scalability and reliability - you must manage multiple components e.g. Redis, PostgreSQL (a fully managed cloud version is available). Data exporter only available in enterprise version.
What we like: Work from a CLI, interactive TUI or web UI. Doesn’t pollute your repo (everything lives in .git) and interactions are like normal Git (add, push, pull, etc). Issues can live alongside the code repo they belong to. Can bridge with GitHub, GitLab and JIRA so you can use git-bug and others can stick with a centralized server.
What we don't like: Web UI is currently read-only. Does not support media file attachments. Not a stable release yet, but still worth playing with.
What we like: Can be used as a database server or as a library. Acts as a k/v store or can be queried using SQL. Storage agnostic - can even be S3. Built-in Prometheus endpoint. Can disable synchronous indexing to increase performance. Supports PostgreSQL wire protocol. Interesting use case as a secondary database for cryptographic verification of the primary.
What we don't like: Only Go SDK is fully developed - others still in progress. No replication or hot backup support yet.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Supports input from a file, URL or stdin so it can be piped to grep and properly searched. Allows the full path to be revealed. Colorizes output. Easily diff sets of JSON. ungron reverses the conversion, so you can pipe grep results back to JSON. Cross-platform binaries available for Windows, Linux and Mac.
What we don't like: You could just use jq which has more features, but it assumes you know more about your JSON data structure. gron is deliberately simple and grep is well known.
What we like: Allows you to move between stacks of commits without using branches. `git move` is implemented in-memory so is faster than `git rebase`, which works on-disk. Interactive `git undo` command helps fix commits, merges, rebases, checkouts and branches. Smartlog command visualizes work without branches (unlike `git log --graph`).
What we don't like: No release binaries - must be installed (and compiled) with Rust’s cargo. Not designed to handle untracked files.
What we like: Lots of desktop and mobile browser versions, including very old devices and new betas. Can write tests in open source Selenium or Cypress frameworks. Tests can be automatically compared against previous runs. Integrates into CI/CD to detect regressions. Geotarget features can test localization e.g. currencies, time zone changes etc.
What we don't like: Mobile tests are executed on emulators (real device support currently in beta). No support for testing on Linux.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Displays line numbers. Side by side view. Can be used independently from the terminal, but configured through git means it supports all git features outputting code. Highly configurable theming and output options e.g. colors, line number styles. Cross platform and OS packages for multiple systems.
What we don't like: Colorized output does not follow the current terminal theme - must be independently configured.
What we like: Runs the commands from your Procfile or Docker Compose config e.g. running separate commands to launch your project’s UI and API. Aggregates logs into a single, colorized terminal output. Local web GUI allows log toggle, search & filtering, manage spawned processes and other resources e.g. Docker storage. CLI can control processes, query logs and daemonize.
What we don't like: Weird, custom open source license. Web docs could do with expanding - CLI has a useful builtin help command though. No OS packages - binaries for Linux and macOS only.
What we like: Local evaluation of feature toggles avoids network latency. SDKs for all major languages. Proxy module means it can work even for single page apps. Support for gradual rollout and user segmentation strategies e.g. by user profile fields. Tech debt dashboard tracks use of feature flags and warns if they are unused.
What we don't like: Unclear how to deploy in a high availability configuration. Limited usage stats (evaluations over the last minute and hour).
What we like: Highlights dependencies and related code structure. Code maps auto-update with each commit - map diffs posted into GitHub PRs. Can build step-by-step tours for onboarding new devs into the codebase. Auto heat maps by latest activity, creation date or commit count.
What we don't like: Requires GitHub. Currently only supports dependency resolution for 4 languages (Python, JS, Java, Go).
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Uses terminal theme colors. Layout makes it easy to read. Tree option shows parent and child processes. Can look into Docker to reveal container name & commands. Watch mode like top. Columns can be configured at run time or in a config file. Can show ports processes are listening on. Cross-platform support.
What we don't like: macOS and Windows support is experimental (worked fine in our tests). No pager on Windows. Search is case sensitive.
What we like: Ranking algorithm means it usually guesses which path you mean so you can navigate common long paths without typing them all out. Multi-platform options for installing. Includes an fzf-powered interactive mode. Integrations available for Emacs, Ranger, Neovim. Zsh autocomplete available.
What we don't like: Years of muscle memory using cd means you probably want to alias it to zoxide. Renamed paths can confuse the history - need to edit the DB to update them.
What we like: Auto connects to Brave, Firefox, Chrome, terminal, Android, Edge or acts as a generic proxy. Inspect all HTTP requests. Create rules (match on regex, URL, host, JSON, headers), intercept and rewrite - pause requests to manually edit them, time out, transform, forward to different hosts or return fixed responses. Open source.
What we don't like: No support for Safari, iOS or Docker (on the roadmap). No free trial for pro features like import/export HAR, more advanced rules, mock API templates, etc.
What we like: Quickly examine or search the full contents of any container - files, layers, Dockerfile. Visual diff of file system, image metadata, and Dockerfile between container versions makes it easy to see what has changed. Examine popular public images and connect private registries (Docker Hub, GCR, AWS ECR).
What we don't like: Does not yet support GitHub Container Registry. Would like to see saved searches or suggested alerts to monitor for common issues with new versions.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Methods for enforcement at request and field level. Relations allow hierarchical access control. Data filtering converts policy expressions into DB query plans to efficiently retrieve only the data that matches the filter. Generic policy language is evaluated locally by language-SDKs (NodeJS, Java, Python, Ruby, Go, Rust).
What we don't like: Provides the hooks for framework / ORE integrations but you still need to build them. Currently focused on backend auth - anything frontend you need to figure out yourself.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Helps validate files, APIs and configs e.g. k8s files. Definitions start broad e.g. types then narrow down e.g. values, so it is easy to get started, but still supports specific validations. Language is a JSON superset. Supports comments (unlike JSON!). Can extract existing definitions from Go and Protobufs.
What we don't like: Documentation explains the concepts well but is missing a “from zero” getting started tutorial (the k8s tutorial is good, though).
What we like: Stores access credentials in native OS storage e.g. Windows Credential Vault, macOS Keychain. Easy to switch between credentials e.g. AWS IAM, Azure User. Session credentials are temporary, minimizing risk of leaks and making them easy to rotate. Open source.
What we don't like: Only supports AWS and Azure. No U2F support. Supports some federated identity providers e.g. Okta, GSuite, AWS SSO, but only to AWS and Azure.
What we like: Supports all API protocols (REST, GraphQL, TCP, gRPC). Handles API versioning and deprecation. Hot-reload without dropping requests. Minimal dependencies (Redis for distributed rate limits and tokens). Drop-in products for developer portal + docs, analytics, social auth, management dashboard. Open source or cloud options.
What we don't like: Architecture gets complex once you start to add the extra components, which are also not open source. Historical performance issues in older versions due to overhead of some features enabled by default (reportedly now fixed).
What we like: Catches common issues which can either be fixed as part of a PR and/or blocked by CI. Can open “Autofix” PRs for code issues as well as linting errors. Examines docs and code coverage and reports metrics for both. Image badges for readme files. Can configure analysis via a config file in the repo or via the UI. Self-hosted version available.
What we don't like: Doesn’t explain “why?” you should make the suggested changes or follow its rules - good to fix errors but better to understand how to avoid them in the future. Autofix can’t solve everything (yet?).
What we like: Abstracts auth and storage so you can use P2P decentralized tech like IPFS without worrying about the underlying protocol. Web Native File System works across platforms and has a POSIX-style interface. Supports storage/execution of WebAssembly modules which are then available on every platform. Open source.
What we don't like: Auth tokens live in browser storage so you could lose access if you clear the data. Risky to rely on such an early new backend tech that is not yet standardized and built by a new startup (everything is open source so you can run it yourself).
What we like: Web demo allows you to query any public repo (+ GitHub issues), or download the CLI. Can do complex queries like commits by email domain, most frequently changed files, filter by branch. Supports querying GitHub API e.g. query stars, repo language stats, issues/PRs. Outputs as an ASCII table, JSON, CSV or SQLite file for other tools to query the results.
What we don't like: Queries can be slow - several seconds. Read-only queries. Only integrated with GitHub Issues (for now).
What we like: Code structure search on syntax e.g. function arguments, multi-line blocks, JSON structures. Can scope to repos (public / private), commit diffs/dates, languages. Option for self-hosted indexer for private code. Browser & IDE extensions for quick search and overlay on top of existing tools e.g. GitHub/GitLab PRs. CLI or web UI (with dark mode).
What we don't like: No custom theme support for the web UI. Can’t search issue trackers.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Build & execute HTTP, GraphQL & WebSocket requests. Syntax highlighted response parsing. Generate code to execute requests via curl, Go, Python, and other languages. Save config to local storage or GitHub Gist. Also available as a Chrome or Firefox extension. CLI in beta. Open source.
What we don't like: Can’t automate a chain of requests - have to manually set up each request. Can’t support cookie headers due to browser security limitations.
What we like: Quickly build interfaces to existing databases. Proxies queries to the data source so results are not stored. Easy form construction with validation and data binding. Can use JS to write data transformations (both read and write). If the GUI concepts are too restrictive, you can always fall back to JS to customize widgets. Open source so you can host it all inside your own network.
What we don't like: No user collaboration in the UI editor so others editing the same project can overwrite each other. Your UI config is stored inside Appsmith’s database (MongoDB) so you can’t use version control (can be exported to JSON).
What we like: Supports staging / non-staging environments. Datasources can be databases like MySQL and Postgres or APIs like Stripe, S3 or GraphQL. Can query all sources with SQL even if they aren’t databases. Everything is a JS object you can manipulate. You can build your own custom React components. Can configure your own Redis/Memcached cache.
What we don't like: Not open source, but there is a self-hosted option. Ability to sync to Git is enterprise-only. Doesn’t support complex logic e.g. multiple API calls.
Snyk Open Source
Snyk Open Source
Dependency security monitoring for open source.
What we like: Easy to see security status for everything. Scans full dependency tree revealing your actual security posture e.g. vulns in dependency dependencies. Relative severity scoring helps understand how relevant issues are. Inspects containers & OS packages as well as code. Separates dev dependencies from prod. Multiple options for fixes e.g. via CLI, not just PRs.
What we don't like: Showing vulnerabilities in dependency dependencies is interesting, but what are you going to do about them? CLI to apply fixes still in beta (Python only).
Security Scorecard, from OSSF
Security Scorecard, from OSSF
Security health metrics for open source.
What we like: Assessment criteria are objective, consistent and documented so OSS projects can start to adopt them. Makes it easy to assess the security posture of the projects you rely on. CLI output is clear why a check fails. Can scan a GitHub repo or infer it from npm, pypi or rubygem package names. JSON or CSV output means results can be scripted.
What we don't like: Some assessment criteria (such as looking for commits from >1 GitHub organizations) may be onerous for small, one-person projects. No easy way to integrate into CI/CD yet (on the roadmap).
What we like: Components to easily add live presence (live cursors, chat and reactions). Abstracts away the backend implementation challenges - networking, performance, presence detection, multi-browser support. Vendored as React / Node packages. Auth hooks to validate user permissions. Examples for raw JS, Next.js, Nuxt.js and React + Firebase.
What we don't like: Assumes you’re building with web technologies i.e. JS. No mobile support. Still requires implementing authentication. Classic build vs buy - is it a good use of your time to try and build this?
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: SDKs for React, JS, iOS and Android to build video / audio without needing to understand WebRTC. Selective Forwarding Unit server makes it easy to scale from P2P to supporting large numbers of participants. Server scales horizontally using Redis as the backend. Automatically supports different connection types (UDP, TCP, TURN) and simulcasting.
What we don't like: Still need to set up SSL + load balancers. Using a server component defeats the idea of P2P. Your code still needs to deal with issuing access tokens to each participant. Simulcasting only works in the browser/JS SDK.
What we like: Multiple browser panes side-by-side to test various sizes. Inspect element works across panes simultaneously. Scroll sync helps comparison. Built on Chrome so devtools available. Shows Web Vitals scores. Can trigger media features e.g. prefers-color-scheme, reduced-motion. Debug tools like a11y, CSS injection, disable images, mobile reachability.
What we don't like: Signup/license key process is a bit fiddly. Quite CPU intensive. You need a very big screen to see all the windows properly.
What we like: Built for JS applications to allow read/write to properties whilst avoiding conflicts. Maintains a history of all changes. Network-agnostic but includes a sync protocol for send/receive messages. Custom types for conflict free counters, collaborative text editing and tables. Follows the idea of functional reactive programming.
What we don't like: Documents are not actually immutable by default - you just code as if they are. Enforcing this can be turned on but has a major performance hit. Implementation is only in JS but versions in Rust, Swift, Python in various stages of development.
What we like: Quick start a P2P encrypted call + screen sharing session. Quality settings go up to 5k to make code crisp and easy to read, unlike generic conferencing services. Easy to take control to type, send through keyboard shortcuts, highlight areas of the screen. Live call debug info to see any connection problems. The “ship it” stamp effect is fun.
What we don't like: Really needs a high quality connection otherwise you can’t reach the higher resolutions and the mouse/keyboard sharing is laggy. macOS only - Linux client on the roadmap for 2021.
What we like: Autocomplete is accurate - speeds up work on a line-by-line basis, just like GMail/Google Docs. Understands file context - imports, variable names, etc. Using comments to describe what you want to do then reviewing suggestions is like doing a web search. Time saver for simple, common, but annoying tasks e.g. regexes, test skeletons.
What we don't like: Not clear if it’s thinking or not - sometimes you wait for nothing to happen. Licensing questions remain unanswered - is the code a derivative of copyrighted material? Doesn’t understand project context.
Waypoint, from Hashicorp
Waypoint, from Hashicorp
Build, deploy, and release across platforms.
What we like: Single command to get your code into production. Can track Git repos to auto-deploy. Integrates with AWS, Azure, Google to upload artifacts, configure LBs, DNS, env vars, etc. Stream logs and execute remote commands. Preview URLs for staging. Web dashboard summarizes deploy status. Extensible hooks via plugins.
What we don't like: Assumes your app is containerized. Need to run / maintain your own Waypoint server - still early so not entirely prod-ready. Preview URLs are public so you must set up authorization or disable them (self-hosting URL service is an option, but complex).
What we like: Built-in tabs, panes, sessions, resizing, scrollback. Shows (customizable) keybindings to help discovery. “New pane” algorithmically placed in the most optimized position (or use manual splits). Can configure layouts in yaml then auto start them. Single compiled binary. Has a built-in file manager (a clone of ranger). WASM-based plugin system.
What we don't like: Colors not inherited from existing shell config. Docs are still very limited. Some core shortcuts used by other tools e.g. Ctrl + r in bash (use Zellij lock mode to pass these through). Slightly laggy over remote connections (compared to tmux).
What we like: Really simple way to execute HTTP commands but can also send more complex requests e.g. headers, file uploads, cookies, JSON. Can write commands in plain text, JS, or define variables in templates. Prettified and syntax-highlighted response parsing. Can save to local browser storage (GitHub and others on roadmap). Open source codebase.
What we don't like: Requests run through a proxy rather than your browser (due to CORS), but localhost URLs are routed directly. No support for OAuth APIs.
What we like: Single compiled binary. No bootstrap requirements - supports many platforms. Can query password manager for secrets and supports encrypted files. Configs can be templated for differences across environments. Can run scripts, including run-once (ideal for cloud IDEs or ephemeral environments). File edit flow similar to git (which is used for versioning).
What we don't like: You can edit files directly but using the edit flow ensures changes/conflicts are handled properly, which may require retraining muscle memory. Doesn’t handle git subdirectories e.g. Oh My Zsh particularly well (better to use a script to install outside of chezmoi).
What we like: Lookup IP details such as ASN, location, hostname, abuse contact, tor/VPN/hosting IP categorization. Cross-platform binaries. Colored output. Bulk summarize IPs from a file (or piped in). Bash, zsh, fish auto-completion. SDKs available for major languages.
What we don't like: Responses not cached. Available via Homebrew on Mac but not Linux or Windows package managers. No man pages.
All reviews are editorially independent, and partners must meet our selection criteria.
What we like: Focus on high-performance repo parsing using async means the UI is responsive, low memory and low CPU even for the largest of repos. Keyboard control of common tasks e.g. stash, stage, diff review and commit with keybindings highlighted for newer users (or when you forget). Adopts terminal color scheme. Cross-platform packages (Arch, Fedora, Homebrew, Chocolatey, Nix).
What we don't like: No log search or file history log and does not yet support bare repos (all on the roadmap).
What we like: Real-time change indicators show where others have made changes to files but not yet committed. Preview live diffs and get warnings about conflicts from other collaborators. Privacy option to stop sharing when required. Built-in video calls and codesharing which works across IDEs - VS Code, JetBrains, Android Studio.
What we don't like: Requires everyone to use GitLive and one of the supported editors. Uploads code diffs (not the full source) to GitLive servers while changes are uncommitted, deleted once pushed.
What we like: Terminal-based signup/demo. Template / version control production commands - scripts, databases, containers, cloud consoles. CLI or Slack Bot to trigger them without direct prod access. Auth/approval flows before commands execute. Optional self-hosted runner with secrets stored in your own secrets storage. Auto-redaction of sensitive logs. Bastion SSH support.
What we don't like: Cloud version requires public access to resources e.g. database connection URL, and doesn’t support IP allowlists - self-hosted runner allows private network access. Reliant on Slack for approvals, team management, etc.
mkcert, from Filippo Valsorda
mkcert, from Filippo Valsorda
CLI for managing local dev certificates.
What we like: Solves the hassle of configuring SSL for local dev endpoints by configuring and managing a root CA. Means you don’t need to leave testing SSL to staging (or prod!) or store real certs locally. Allows you to generate certs for localhost. Cross platform + support for browser specific root stores.
What we don't like: You still need to configure your server to use the certs. GitHub binaries built with a slightly older version of Go (1.13) so no Apple Silicon support - use the homebrew version which does have Apple Silicon binaries.
What we like: Packages ranked based on various criteria such as documentation, performance, popularity. Categories for common use cases to help find most used packages. Analyze dependencies and project activity e.g. release cadence, commit frequency.
What we don't like: Only supports searching JS packages - leaderboards available for Python, Rust, Go, Swift and Java libraries. Some criteria are more subjective than others e.g. are frequent commits good or bad?
What we like: gitmoji helps identify commits at a glance. CLI sets up a Git commit hook to trigger the interactive CLI to pick a gitmoji for the commit. Text search to find right emoji based on commit purpose. Can be configured to use Conventional Commits scopes.
What we don't like: By default only renders on GitHub, but you can configure it to use actual emoji characters. Some may consider this polluting the git log, especially if you write your commits properly and use git shortlog in your release notes.
What we like: Can do arithmetic, import modules, use data types, loops, etc, because everything it receives is interpreted with Python. Tab completion based on man-pages. Community extensions e.g. Powerline, written in Python. Cross-platform.
What we don't like: Small community of extensions. Not bash compatible, so you have to relearn some syntax. Incompatible with Python virtual environments (has its own replacement called vox).
htmx, from Big Sky Software
htmx, from Big Sky Software
HTML attribute-based frontend framework.
What we like: Access AJAX, CSS Transitions, WebSockets and SSEs directly in HTML. Any HTML element can issue AJAX requests. Implements the principle of “locality of behavior” so it’s easier to understand what code is doing. Small (10k min gz), no dependencies.
What we don't like: Injecting remote responses is a potential security issue: JS can still be executed even with a restrictive CSP, and user-generated content must be escaped. Execution must be denied within specific areas of the DOM. Violates separation of concerns principle.
What we like: Open source, runs locally and/or in CI/CD. No DSL - write rules in the language you use and alongside the code they check. Plugins for as-you-code analysis in Vim, VS Code, IntelliJ. Lots of community rules for common languages and frameworks (Django, Flask, Java, Rails). Integrates with CI and can add comments to PRs. Cloud web UI is optional.
What we don't like: Experimental support for C, Rust, PHP, Lua, C#, Kotlin. No Windows support.
What we like: InfluxDB-compatible ingestion. Postgres-compatible wire API (allows querying with Grafana). Handles out of order inserts in a configurable way even though it uses an append column-based storage model. Official Docker image and Helm chart for dev/prod deploys. ANSI SQL with additional time functions. No GC.
What we don't like: No built-in replication/clustering. Partitioning is only supported by timestamp (day, month, year) which means you tradeoff easier retention policies and faster calculations/seek times with the potential for hotspots if reads are mostly on recent data.
What we like: Search shell history with CLI or interactive TUI (ctrl+r). Query by date, current directory, string terms. Encrypted sync across machines with log of exit code, session, command. Fun stats e.g. “most used command”. Option to run your own sync server.
What we don't like: Can’t delete entries from history. Default rebind on up-key takes some getting used to, or disable it in config. Only supports zsh and bash.
What we like: Google Docs-style real-time sharing / editing. Detects dependencies, prompts for pip install and updates requirements.txt. Running the Jupyter environment in the cloud saves hassle installing kernels locally. Integrates with git. Public links. Supports Python & R.
What we don't like: Visualizations are custom HTML embeds when exported to Jupyter notebook format - better to embed something like Plotly in code to ensure portability.
What we like: No dependencies. No build step. Very small (~400 LoC vDOM, ~100 LoC state management, ~230 LoC HTML helpers). Works with async components. Web tutorial does a good job explaining how it works (built using itself).
What we don't like: No router. Great for very simple SPAs, but something like Mithril.js (or Vue. Or Svelte) probably needed for anything of significance (if you don’t mind the build step).
What we like: Saves building your own queuing system - acts as a proxy to store and forward webhooks. Set up throttling and retry rules. Mirror inbound webhooks to multiple destinations, including a local CLI for testing. Alerts on failures - allows you to search & retry failures so you don’t lose any data.
What we don't like: Assumes your webhook destinations are idempotent with “at least once” delivery. No support for signature verification - will forward all requests (you can configure schema filters), so you need to implement this yourself. No support for custom webhook URL domains.
What we like: Local simulation of the GitHub Actions environment using Docker. Much faster than commit/push for testing changes. Supports environment variables and secrets. Can trigger specific events e.g. pull request, push, and jobs within workflows (including skipping steps).
What we don't like: Only supports Linux runners (host is multi-platform). Full Docker images are quite large (>20GB), but you can try slimmer images with fewer bundled tools.
404 Tools Not Found. Try changing the filters.
Interesting Tools by email
Our free weekly newsletter picks out the 2-3 most interesting tools. See the latest email.