Each week Console reviews the best tools for developers.
✦ Disclosure: All reviews are editorially independent and partners must meet our selection criteria.
Authentication and authorization.
What we like: Provides user signup, login, and role-based authorization flows. Supports social logins, SSO, SAML, multi-tenancy & passwordless login methods. SDKs for most languages & tech stacks, with REST APIs for everything else. Can integrate with API gateways like Kong and AWS API Gateway. Can be self-hosted or cloud hosted.
What we don't like: WebAuthn and passkeys are only available in more expensive plans. Default UI looks a bit dated, so you will want to customize it.
What we like: Send things into the pastebin via SSH and get a shareable web URL. No signup required - uses your SSH key. Viewer supports syntax highlighting and markdown parsing. SSH in for a full terminal UI to manage snippets. Each snippet can be set to private with an expiring URL. Can also be self hosted.
What we don't like: Can’t search the snippets once they’re uploaded.
What we like: Write your docs using MDX and React and store them in Git. Layers a nicely designed web UI with dark mode, search & SEO optimization on top. Supports a range of common components like code, callouts, cards, tables, snippets. Includes API documentation from specs like OpenAPI. Has a local dev CLI.
What we don't like: Limited customization options - makes everyone’s docs look the same.
Deploy ML models.
What we like: Build & deploy models from Jupyter notebooks. Provides an inference endpoint accessible via a REST JSON API and from within data warehouses e.g. from SQL, Redshift, or Snowflake. Supports custom environments, packages, tests. Can also run training jobs from a notebook or from Git. Includes logs, monitoring & version control.
What we don't like: Everything is based around Python & Notebooks - this is the standard ML stack, but worth being aware of if you’re using something else.
Build terminal apps with React.
What we like: Use React & components to build interactive command line interfaces. Built-in components for text, colors, flex boxes, borders, hooks, working with stdin and stderr. Supports CSS-like props, testing and all features of React e.g. Devtools. Various open source components e.g. progress bar, table, form.
What we don't like: There’s a significant productivity gain from using React across web, terminal, mobile, etc, but purists might argue CLIs should be built in a more appropriate language like Go or Rust.
CLI to save web pages.
What we like: Save web pages to a single HTML file with all assets embedded - means you can load sites offline (or share them). Options to exclude specific assets e.g. videos or audio. Chrome extension is also available. Written in Rust, so is available as a static binary with packages for all major OSs. Open source.
What we don't like: Has no JS engine, so some sites may be broken or not work at all. You can pipe it through a headless Chromium to act as a pre-processor though.
Event processing for developers.
What we like: Easy to run locally in Docker (1 command to get running). SDKs for Node, Go, Python, .NET, Java to produce and consume messages. Also has a REST API. Supports storage in memory, on disk, and remote e.g. S3. Native cluster mode for redundancy. Built-in web GUI for management.
What we don't like: Common queue protocols (AMQP, MQTT) are on the roadmap. Clustering requires k8s.
Monitor a process, trigger a notification.
What we like: Single binary CLI which triggers a notification when the process completes. Prefix the command with noti or attach to an already running process. Local notifications by default, but also supports services like Slack, Telegram, Twilio, or speech. Works on macOS, Windows, and Linux. Open source.
What we don't like: Packages only for macOS (Homebrew) - Windows and Linux need to download the binary. No official binaries for ARM.
Remote API simulation.
What we like: Intercepts remote APIs via a proxy, storing the responses so they can then be simulated. Modify the API behavior locally e.g. mocking responses for testing. Supports sequenced requests and state across requests. Introduce chaos e.g. latency or status code randomization. Static binary. Open source.
What we don't like: Getting started docs are unclear. Native language bindings only for Python and Java, but you don’t really need them (they just make a few things easier, like HTTPS).
What we like: Build complex workflows with triggers from third-party apps (AWS, forms, SaaS, APIs, etc), webhooks, cron, email, and others. Process data and create conditional branching with filters and loops. Take actions with the results e.g. send to Slack, create calendar invites, trigger other functions. Drag & drop UI and write JS code. Cloud or self-hosted.
What we don't like: Cloud-hosted version requires a credit card for free trial signup. Cloud instances don’t auto-update to newer versions.
Self-hosted Heroku alternative.
What we like: Provides an orchestration layer and web UI for installing and managing self-hosted services. Provision databases and common apps like Ghost, MinIO & Plausible Analytics. Includes pre-packaged setup for common frameworks (NextJS, Deno, Laravel) and languages (PHP, Python, Rust). Can also run generic Docker containers. Open source.
What we don't like: Runs on a single server, which is great for self-hosting non-critical apps, but you then have to deal with server admin, updates, and scaling it yourself.
What we like: API-compatible with both Redis and Memcached, but with performance and scalability improvements. Benchmarks ~1ms P99 latency. Supports Redis and HTTP protocols. Includes an HTTP console & Prometheus metrics endpoint. Scales up to 1TB memory per instance and shards across CPUs. Single binary. Cloud & self-hosted.
What we don't like: Targets Redis 5 API compatibility - other versions in progress.
What we like: Supports classic feature flagging with targeting rules, but also enables experimental A/B testing, gated permissions, and ops rules to handle slow-rollout of backend changes. Separate by prod, staging, dev, environments. Feature opt-in allows users to manage their own involvement. Has both client and server-side SDKs.
What we don't like: Dark mode is available, but it’s hidden behind a beta feature flag! No Rust SDK.
React component library.
What we like: Free & open source library of UI components including form fields, navigation, data display, and layouts. Looks good (including auto-dark mode) out of the box. Fully customizable on each component and/or through global themes. Includes accessibility features. Extensive docs and examples.
What we don't like: Not yet at v1, but approaching stability. Missing some components you might expect e.g. full app containers and certain UI containers.
Terminal cheat sheets.
What we like: Nothing to install - just curl the URL e.g. curl cht.sh/ls to get the cheat sheet for the ls command. Can also be queried by appending a search term after. Also covers programming languages & databases e.g. ask how to open a file with Golang with curl cht.sh/python/open+file
What we don't like: There is a locally installable client, but it requires Python 2 and doesn’t install on Apple Silicon systems. Better to stick with the web client.
Notepad for developers.
What we like: Developer focused log-style entry note format makes it quick to add time stamped notes as you’re working on things. Keyboard optimized, with optional vim keybindings. Tiny mode can float on top of all your other windows for easy access to manage notes. Attach code, images or make notes todo items. Use offline or with cloud sync. Markdown formatting.
What we don't like: Notes stored in a database on-disk, but can be exported to JSON. Theme doesn’t switch based on system settings (have to manually toggle dark or light mode).
What we like: Toolchain helps manage protobuf APIs. Single library provides full gRPC support, but also allows usage of gRPC compatible HTTP clients for both HTTP1 and HTTP2. Useful where non-HTTP clients don’t yet work, such as in WebAssembly or Edge runtimes. Can generate both client and server SDKs. Drop-in OpenTelemetry.
What we don't like: Docs have no search. Some clients still in beta e.g. Node.
Open source session replay.
What we like: Combines frontend and backend SDKs to provide end-to-end session replay and error tracing. Backend logging integrations link up to the relevant user session for easier debugging. Records network activity & console logs. Supports data masking for privacy. Open source so can be self-hosted, or use the cloud version.
What we don't like: Can’t track WebSockets. Frontend session tracking has some client overhead (11kb bundle). The UI has no dark mode.
SDK generation & API management.
What we like: Generates type-safe and idiomatic SDKs from your API specs for Go, TS, Java, Python & PHP. Can output them to GitHub (individual or monorepos). Output can be customized e.g. adding comments, changing class names, custom HTTP clients. Automates generation in CI and publishing to package managers. Provides API key management & dev portal.
What we don't like: Only supports OpenAPI v3 specs or JSON schema files.
What we like: Execute commands and define desired state across many remote machines, containers, or locally. Can install packages & manage config files. Understands groups, roles, multiple environments & typed actions against databases, firewalls, Git, etc. Can integrate with Terraform, WinRM, Docker, Ansible, and others. Extendable with Python.
What we don't like: Use of Python means it doesn’t require an agent, but obviously means it requires the Python runtime environment locally (remote side only requires a shell) and must be configured in Python.
Self-hosted dev environments.
What we like: Create self-hosted remote dev environments locally (Docker) or in the cloud (GCP, AWS, Azure, Digital Ocean, k8s). Connect via VS Code, JetBrains, SSH. Create workspace templates via Terraform. Connect via port forwarding and share URLs using P2P WireGuard or Coder-provided relays. Supports dotfiles & secrets. Browser GUI or CLI.
What we don't like: Common issues with remote dev environments include latency and inability to work offline, but are these just edge cases? Requires some work to get Docker in Docker set up or you could use a full VM instance per workspace.
Infrastructure for internal tools.
What we like: Internal tools as code - write scripts, workflows, dashboards, custom UI for internal tasks. UIs are built using React. Connects to resources like databases & APIs. Provides infrastructure for logging, permissions, approvals, notifications, etc. Supports multi-step tasks & scheduling. Supports local development and self-hosting.
What we don't like: Limited language runtime support (TS, JS, Python, Shell, Docker). The UI doesn't support dark mode.
What we like: Docs written in Markdown (MDX, with React component support). Built on top of Next.js. Native support for docs concepts like sections, tabs, callout, syntax highlighting. Supports server side generation from remote sources e.g. GitHub star count. Static search. I18n support. Dark mode. Open source.
What we don't like: Design customization is somewhat limited - you need to create a custom theme from scratch if you want to do more than minor tweaks.
What we like: Supports load testing and functional (assert) testing of APIs, message brokers, ecommerce systems, etc. Supports HTTP, WebSockets, Socket.io, HLS, file uploads, and other protocols via plugins. Reports p50, p95, p99, min and max. CI/CD runners to conduct continuous testing. Test scenarios written in code. Open source + cloud platform for distributed tests.
What we don't like: Can integrate with Playwright for headless browser testing, but this is experimental and the primary use case is backend testing.
What we like: Aggregates observability data from multiple sources (CloudWatch, Prometheus, Datadog, Grafana, etc) to calculate Service Level Objectives. Normalized data across sources - powerful query language for accessing the right data. Can be configured in code (YAML, Terraform, OpenSLO standard) or via the UI. Visual service health map dashboard view.
What we don't like: UI has no native dark mode. Can be complex to set up from scratch (docs provide useful examples and templates for some platforms e.g. k8s).
Open source CI.
What we like: Self-hosted. Each step is isolated and runs as a container. Define the commands in a config file in your repo with any Docker image as the context. Uses a persistently mounted volume to pass input/output files through the steps. Flexible conditional execution, supports matrix builds, services e.g. databases. Backed by SQLite by default.
What we don't like: Limited pre-built images and plugins - smaller ecosystem than GitHub Actions, for example. Self-hosting is the point, but it does mean you have to run and manage everything yourself.
A better cat (file viewer).
What we like: Replaces cat. Supports syntax highlighting and has a Git integration showing modifications in the gutter. Includes line numbers (by default, can be disabled) and a pager. Detects non-interactive usage and turns off all the fancy features for full cat compatibility. Single, open source Rust binary with packages for most platforms.
What we don't like: Line numbers get in the way of copy/paste, so you need to remember to launch it with the -p plain flag as needed.
What we like: Create forms visually with simple flows or more complex logic e.g. variables or conditional steps. Integrations for submitting data to databases e.g. Postgres, webhooks, Slack etc. Also supports signup and login flows (Stytch & Firebase). Drop in with JS or use a React component to fully customize the form.
What we don't like: Can be integrated using a React component, but the config is in the cloud not your code. No UI dark mode.
What we like: Write event-based background tasks in TypeScript to be triggered by webhooks, custom events, or scheduled. Supports delays, run once, trigger via a separate SDK. Runs as a Node process inside your infra so can connect to private resources. Integrates with Slack, GitHub, Notion. Partly open source.
What we don't like: You run the workflow code yourself, but triggers are via their SaaS platform which can’t (currently) be self-hosted. Workflows can’t yet be run on serverless platforms like Lambda or Vercel.
Progress between pipes.
What we like: Insert into any pipe to provide a visual progress bar. Shows data transfer rate, time taken, percentage complete, and completion ETA. Supports multiple pipes to show progress between them all. Can optionally limit data transfer rate. Supports all major Unix-like OSs. Open source.
What we don't like: Latest release is Sep 2021, but it seems stable so that’s probably not an issue. Some reports of unreliability if backgrounded.
What we like: Simple CLI to compress or decompress. Automatically detects the right algorithm based on the file extension (or file signature) - no need to specify flags. Can decompress multiple files of multiple types in one go. List archive contents (with tree view). Static MUSL (Rust) binary. Open source.
What we don't like: .zip doesn’t support streaming. Doesn’t support adding/removing files from an existing archive.
Offline API docs.
What we like: Web search and reader UI for programming documentation. Covers lots of languages, frameworks, APIs, products. Keyboard shortcuts and easy search. Search can be scoped and can also be installed into the browser address bar. Offline support & dark mode. Open source.
What we don't like: Works by scraping the web so there’s the potential to be out of date or missing certain docs. You have to enable specific docs to make them available.
Web scaping automation.
What we like: Uses TypeScript and integrates with (abstracts) common headless browsers like Puppeteer & Playwright which makes it easier to keep scripts up to date. Manages queuing, storing results, scaling & proxies. Extensive docs and examples. Open source.
What we don't like: Primarily designed to run locally (or in Docker), but there is a commercial SaaS option for hosting and scaling in the cloud.
What we like: Drop-in JS, Go, Java, or NodeJS SDK for automating anti-fraud, bot detection, account takeover protection, and device verification. Supports client- and/or server- side integrations to protect frontend and backend endpoints. Can connect to third-party services for additional sources of intelligence. Trigger challenge responses like MFA or ID checks.
What we don't like: SDK supports a limited number of backend languages. UI has no dark mode.
What we like: Desktop app for diffing text, images, binary, PDFs, and folders. Configurable comparison layout - side-by-side, fluid, in-line, or split view (images). Can ignore whitespace. Can be used as version control diff from the terminal or integrated into your IDE (JetBrains, VS Code, Android Studio, XCode, etc). Send files to ksdiff CLI to launch diff or trigger merges.
What we don't like: macOS only.
Overview of a directory
What we like: Fast directory browser with a tree explorer that filters files to make it usable within the terminal window. Tree expands as you search and browse so you don’t lose your place. Search doesn’t block - the next keystroke interrupts. Supports commands with live updating views. Preview files. Stage file changes. Single (Rust) binary.
What we don't like: Some keyboard shortcuts don’t work by default on macOS e.g. open in new panel, so you need to rebind them.
Fake production data for ML.
What we like: Enables privacy compliant training of ML models on realistic fake data. Connects to your prod database via SQL, transforms (fakes) the data, then trains your model. Provides a report after training to confirm how realistic the trained data was. Supports tabular and event driven models. Export to ipynb. Cloud or self-hosted.
What we don't like: No dark mode. Pretty hefty minimum requirements for self-hosting, but ML training is compute & GPU intensive.
Debug with production traffic.
What we like: Records production network traffic for reproducing issues later. Stores traffic on disk, S3 (pro version only), Kafka, ElasticSearch, etc. Middleware supports sanitizing sensitive data, emitting metrics, etc. Speed up replay for load testing on real traffic. Transparently captures traffic without affecting it (it’s not a proxy). Open source (some features are paid).
What we don't like: Requires sudo by default, but can run as a non-root user or by forwarding traffic to it. Windows is not officially supported.
Sticky notes in your terminal.
What we like: Sticky notes board for your terminal. Works with mouse or keyboard-only. Move, resize both sticky notes and the “board” they’re stuck to. Control over the border and background colors. Notes are saved across sessions and stored in a local JSON file. Open source.
What we don't like: No static binary - installed via pip/Python. Main body entry text field doesn’t expand, which makes editing a bit awkward.
Access management as code.
What we like: Link resources in Terraform. Define access rules and workflows in Python. Supports simple approve/deny rules with approvals managed through Slack. But also allows sophisticated rules with routing to teams, auto approval based on who is on call, remove access or de-escalate privileges on events e.g. after going off-call or after a time. Full audit logs.
What we don't like: Requires use of Terraform e.g. no support for AWS CDK. Only supports writing rules in Python.
What we like: Counts lines of code very quickly (millions of lines per second) to output stats for lines, code lines, comments, and blanks. Breaks out counts per language. Understands language specific syntax and supports basically every language. Single static (Rust) binary and can be also imported as a library.
What we don't like: No stable release since Jan 2021, but does have recent commit history.
Dev env manager
What we like: CLI and shell plugin to auto-switch runtime versions based on per-directory configuration. Reads tool versions file(s) to determine which runtime to install and link to. Supports Bash, Zsh, Fish, Xonsh. Supports asdf plugins. Designed for performance by not using shims (~120ms overhead in asdf) instead updating PATH to directly call runtimes.
What we don't like: No Windows support. Can conflict with direnv.
What we like: Catalog and manage all your internal repos, tools, and services. Allows developers self-service access to provision infrastructure, call APIs, and understand ownership. Useful integrations e.g. CI/CD to view deployments, observability for metrics and SLOs, incident management to escalate on-call issues, etc. Pulls in Markdown docs from the repo automatically.
What we don't like: No dark mode. Service config can be in an opslevel.yml file in each service repo, but actions and checks cannot - they must be configured via the OpsLevel UI.
Auto document databases.
What we like: Single binary outputs Markdown documentation of your whole database (PG, MySQL, MariaDB, SQLite, BigQuery, & others) with one command. Configurable output format (Markdown, DOT, Mermaid, JSON, even Excel). Can diagram relationships. Includes linting function e.g. require comments. Can diff actual vs documented.
What we don't like: It’s a documentation tool, not for migrations or actually creating the tables from scratch from the docs. Limited support for stored procedures and functions.
React visualization library
What we like: Web library for plotting SVG charts, maps, network graphs. Modular and framework-independent - works with React, Angular, Svelte, TS. Easily customizable plots e.g. axis, labels, ticks, and styling using CSS variables. Supports events for mouseover and mouseout. Includes a dark theme for all components.
What we don't like: Legend is a separate component. Offers more control, but then must be configured separately from the graph component.
Data import component.
What we like: Drop-in component for CSV/Excel import rather than building your own - React, Vue, Angular, or JS. Themeable. Can validate fields e.g. email, phone, number. Imported data is sent as JSON via webhook or JS callback. Webhook defaults to batches of 1,000 rows to allow you to process them - waits for a response before continuing.
What we don't like: Need to use the JS callback if you want to keep everything on your own servers.
Terminal system monitor
What we like: Single static (Rust) binary that displays a real-time system monitor dashboard in the terminal. Supports widgets for CPU, memory, battery, processes, disk, network. Can expand widgets and navigate using the keyboard or mouse. Configurable via a file, including widget layout. Theme inherits from the terminal or can be customized.
What we don't like: Limited number of widgets. Keybindings not customizable.
Typesafe SQL for TypeScript.
What we like: Prevents mistakes by providing types for SQL queries. Understands fields types, joins, subqueries, aliases, and other advanced SQL features. Also supports dialects from databases like Planetscale, D1, AWS, etc. Enables autocomplete in your IDE. Migrations can also be written in TypeScript.
What we don't like: Only works with Postgres, MySQL & SQLite. A third-party project is needed if you want to auto-generate schema definitions.
Query your infrastructure.
What we like: ELT-like sync from source(s) to destination(s). Sources can be APIs e.g. AWS or GCP resources, SaaS e.g., HubSpot, PagerDuty, or infra e.g. Terraform, Vercel. Destinations can be databases e.g. Postgres, SQLite, or cloud e.g. S3. Full sync or incremental changes. Typed fields. Option to maintain old records or remove them. Open source.
What we don't like: Concurrency may need to be tweaked to avoid rate limits when syncing resources, but this will increase sync times. Incremental sync only supports local state.
Typescript error library
What we like: Library to provide structured errors in JS/TS. Set props on errors with typed fields. Wrap, aggregate, normalize errors. Core library provides base functionality which can be extended via plugins. Official plugins for specialist cases: CLI (colorized, pretty print, verbosity levels), HTTP (structured HTTP responses), clean stack traces, and others. Open source.
What we don't like: JS/TS only. Be sure to configure TS to output ES modules, not CommonJS.
Terminal file manager.
What we like: Minimalist CLI designed just to make it easier to navigate directories i.e. a replacement for cd and ls. Fuzzy search makes it navigating through the directory tree very fast. Shortcuts to preview, delete files, and exit with or with navigating to the directory. Prebuilt binaries for Mac, Linux, Windows. Open source.
What we don't like: Requires a workaround to work properly in PowerShell. Have to trigger fuzzy search on every directory change.
Internal tool builder.
What we like: Impressive level of UI flexibility and customization - simple drag & drop to writing custom JS & React with external dependency support. Auto-generates UIs from database schemas including those tedious features like sorting, pagination, filtering & search. Real browser devtools-like debugger. Can also build native mobile apps and automated data pipelines & workflows.
What we don't like: Themable, but no true dark mode. Remotely querying databases over the internet has inherent latency challenges (you can self-host Retool or use their cloud database).
Breach detection honeypot tokens.
What we like: Generate honeypot files (Word, Excel, PDF, executables) and tokens (AWS) which send alerts when triggered e.g. when a file is opened or the API credentials are used. Also supports DNS record, MySQL dump and other types of honeypot tokens. Email or webhook URL notifications. Provides another layer of detection e.g. from malware scraping credentials from laptops. Free service.
What we don't like: Token types are more-or-less sufficient, but somewhat limited e.g. only supports AWS tokens (Slack tokens were deprecated).
What we like: Easily take input from stdin or a specified file then plot a graph in the terminal. Supports bar, line, scatter, box plots, histograms and density plots. Minimal setup needed - assumes first column is x axis and second column is y axis, but this is configurable. Can handle real-time data. Uses default terminal colors. Open source.
What we don't like: Does not support time series. No static binary - installed via Ruby gem.
What we like: Enables code to live where it belongs - alongside code (in Markdown). Auto-syncs as you refactor, rename, move code around. Comments on PRs when docs break. Supports Mermaid syntax for diagramming. IDE extensions (VS Code, JetBrains) reveal docs in-context with code. Editor supports dark mode.
What we don't like: Need to edit the docs using their editor (or the Markdown directly). In-IDE doc authoring is on the roadmap.
Rich terminal pager.
What we like: Replaces `less`, `more`, or `tail -f` with more features for parsing text - section delimiters, search, mark position, color highlights, and parsing of columnar text. Mouse support with proper select + copy to clipboard. Keyboard shortcuts. Guides for replacing the pager in other CLIs e.g. psql, git, mysql, procs.
What we don't like: Reads the entire file into memory. Default keybindings are different from
Build emails in React.
What we like: Provides a dev environment for creating email templates in React - local dev server with previews and a built-in sender for dynamic rendering at runtime. Supports MJML for creating responsive emails that are compatible across clients. Sending API wraps Nodemailer, which has lots of useful features. Open source.
What we don't like: Unclear whether it runs properly on Windows (there’s an open GitHub issue about this).
Dev team assistant.
What we like: Provides team and task management workflows within Slack. Understands team load to provide warnings when the team might not complete tasks within a sprint. Shows whether team members are overloaded with tasks, including tasks outside the sprint or assigned to others.
What we don't like: Only supports workflows using Slack, JIRA, and GitHub.
Terminal clipboard manager.
What we like: Simple commands to cut, copy and paste. Supports pipe in or out and can read from and write to files (the whole file can be in the clipboard). Use multiple clipboards and show/clear the contents of all. Clipboards exist as temporary files which can be mounted to shared drives to use across systems. Can also make clipboards persistent instead of just temporary.
What we don't like: No support for GUI clipboard manager on Wayland (but supports X11, Windows and macOS system clipboards). Installation defaults to compiling source, but you can download binaries if you prefer.
Containerized dev environment config.
What we like: Well-documented open standard for defining containerized development environments. Supported by several tools for consistent environments locally and in the cloud. Allows the environment to be versioned alongside the code. Can define resource usage limits, environment vars, endpoints. Samples provided in the open registry.
What we don't like: Very k8s centric even though the spec can be used generically. Another standard (see xkcd 927).
Log file viewer.
What we like: Point at a directory and it auto-detects file formats, parses, colorizes, merges, and displays them in your terminal. Can pretty print structured data e.g. JSON. Search as you type also streams in new log lines. Sessions can be restored. Query and filter the logs with SQL, which includes “virtual tables” to allow for comments, tags, and bookmarking.
What we don't like: Official downloads don’t include Arm binaries (although the macOS version via Homebrew is compiled for Apple Silicon). Does not inherit the terminal theme - need to configure custom colors separately.
Scriptable status bar
What we like: Fully customizable - fonts, colors, positions, notch size, animations. Can subscribe to general events e.g. space change as well as OS notification events e.g. Spotify track changed, to trigger scripts. Supports graphing arbitrary values. Items can be linked to spaces. Can pull in items from the macOS status bar e.g. Control Center or WiFi.
What we don't like: Config file is a bit fiddly to work with. Community plugins could be more structured - currently just config files + scripts shared in a GitHub discussion thread.
React dashboard library.
What we like: Makes it really easy to create good-looking blocks for dashboards. Lots of components from graphs to cards, callouts, tables, and toggles. Each component has an API reference. Includes basic application layout and shells. Components are responsive. Open source.
What we don't like: You can choose from 22 different color palettes, but not create custom colors. No dark mode.
What we like: Build a custom dashboard within your terminal. Lots of modules out of the box - IP info, clocks, system status, feed reader, Hacker News feed, GitHub, various monitoring tools, etc. Create custom modules in Go or use a simple command runner module. Customize layout via config file. Cross-platform & open source.
What we don't like: Long config files can be a bit annoying to work with. Some stability issues reported on Windows and if there is no internet connection.
Database on top of SQLite
What we like: Makes it easy to deploy a replicated cluster of SQLite backed database nodes. Writes distributed to a quorum or they fail. Provides HTTP API, CLI, and client libraries for Go, Python, Node, Java. Runs in-memory, but backed by on-disk Raft logs to avoid data loss risk. Supports full-text search, JSON documents, encryption, hot backups.
What we don't like: You must use the HTTP API (directly or via client libraries) to get all the functionality. Writes scale vertically - only reads scale horizontally. 2GB database size limit (switch to on-disk to avoid this, but with a write-performance tradeoff).
Scheduled serverless jobs
What we like: Run a serverless function as a background job, in response to an event, on a schedule, or as a webhook. Supports JS and TS with framework integrations for NextJS, Express, Cloudflare Pages & RedwoodJS. Supports multi-step functions. Local dev server. Functions run on your own platform. Open core (paid cloud platform).
What we don't like: Functions written in JS/TS-only (but you can trigger events from any language). AWS Lambda is not yet supported. You need to register functions with Inngest after every deploy (which can be automated).
Local container management
What we like: Easy to remember commands for building and running containers without having to install/learn multiple tools. Can pull from container registries or build locally (creating an OCI image from a Dockerfile). Supports specifying the platform for running/building for different architectures. Acts as a layer on top of nerdctl so it is effectively Docker compatible, but uses containerd and BuildKit.
What we don't like: macOS only (Windows & Linux are on the roadmap). Docs are limited, so you need to work out the commands from the nerdctl docs.
What we like: Understands infrastructure state to allow parallelized runs and collaboration on infrastructure as code changes. Supports Terraform, Pulumi, Cloudformation, and k8s. Integrates into existing workflows e.g. pull requests. Policies allow RBAC and approval flows, defined using Open Policy Agent. Drift detection. Product has some personality e.g. subtle space references in log output.
What we don't like: The docs are well written, but there is a steep learning curve and a UI with lots of components to work out.
Make logs easy to read.
What we like: Reads logs from stdin and pipes them back to stdout formatted and easier to read. Also adds colors. Options to skip log keys, ignore keys that are the same as the previous entry, and truncate values. Binaries for macOS, Linux, and Windows.
What we don't like: Only formats logs in JSON or logfmt - everything else is ignored. No ARM binaries.
Monitor your cloud dependencies.
What we like: Monitors not just service status pages, but also synthetic tests against APIs to check things like creating an S3 bucket, upload objects, access them, etc. Supports cloud (AWS, GCP, Azure) and SaaS e.g. GitHub, Cloudflare, Google Drive. Degraded (average latency has increased) or down (not responding) alerts. Optional agent to test from within your own account.
What we don't like: The Metrist agent can auto discover API calls using eBPF on the OS level. This allows unknown APIs to be monitored, but has some limitations on the traffic it can inspect e.g. outgoing TLS/SSL calls, but only on Linux if they use OpenSSL (dynamically linked).
Fast build system.
What we like: Smart caching and tasks distributed across multiple build agents significantly improves build time. Only runs build tasks with changes. Remote caches can be shared. Migration functionality can keep all workspace dependencies up to date for everyone. Built-in task executors support linting, testing, dev servers, etc.
What we don't like: All the examples, docs, core plugins etc, assume you’re working in the JS/TS ecosystem, but it is actually a general purpose build system.
HTTP requests & tests with plain text.
What we like: Define and execute HTTP requests in plain text. Config format makes it easy for anyone to understand and manage. Supports headers, query params, form submissions, APIs, CSRF tokens. Can assert responses for testing e.g. content, headers, JSON body, endpoint performance. Runs as a single binary CLI. Open source.
What we don't like: Uses curl underneath, but doesn’t fully support/expose all the features/options. Hurl syntax is custom, so text editors will struggle to highlight and provide autocomplete.
Developer experience for APIs.
What we like: Provides endpoint discovery and request monitoring via middleware, which makes it easy to integrate into an existing API. Records API requests for debugging - can be replayed from the dashboard or via a Postman download. API spec drift detection with alerting. Easily create a dashboard for API users to login and review their usage. Sensitive fields can be masked. Cloud or self-hosted.
What we don't like: API integration and instrumentation SDKs only available for Go, Typescript, Java. Self-service API key rotation not yet supported.
Interesting Tools by email
Our free weekly newsletter picks out the 2-3 most interesting tools. See the latest email