Localhost
Localhost Development As A First Class Citizen
Craftspeople thrive when their tools are right at their fingertips—immediate access, zero latency, full machine power—without the delays of CI/CD pipelines or yet another SSO login.
Have you ever spent an inordinate amount of time iterating on span names and attributes? You make the code change, ship a PR to production, then wait to see the outcome. If you're lucky, only 30 minutes have passed and you haven't gotten distracted by something else.
We have all sorts of tools available in our development environments. We can run incredibly powerful local tests, integrating against locally running databases, Kubernetes, and other production-grade technologies.
But when it comes to observability, this is left as an afterthought. You can spin up a Jaeger container to see traces, or set up a complicated docker-compose file with an observability platform deployed. But this is so onerous that, except for the most diligent and dedicated among us, we almost never do it.
Humanlog brings this experience back to a human level.
We believe that localhost development is here to stay. Having a fast feedback loop on our laptop is critical. What we can easily see, we can easily understand, fix and improve.
Waste
It's no secret that a lot of observability data is never going to be seen by anyone, is wasted, and should never have been emitted in the first place. But as practitioners, it's often difficult in situ to determine whether our service will generate too much or too little observability data. So we tend to err toward abundance.
This wastes resources and money. The solution? Better hygiene. But how can we clean what we can't see? By bringing visibility into your local workflow.
Humanlog lets you iterate and make mistakes on your machine. You don't pay per byte ingested. You own your hardware, your laptop. You don't pollute your production data with tests.
Speed
Production servers can be powerful, or slow. The move to virtualized cloud servers hasn't meant an improvement in overall compute efficiency. Many cloud providers schedule your VMs on old hardware. You can pay a premium to get dedicated modern metal, but this ties back into our previous discussion on waste.
Most of us have pretty powerful machines at our fingertips. A run-of-the-mill developer machine will often have 8 cores and 16GB of memory. No multitenancy, just you and your keyboard.
Humanlog lets you leverage this compute power and isolation for your iteration speed. You can ingest and query a surprisingly large amount of data in quasi real-time on a modern machine with a modern SSD. Bring this back home and work on your telemetry data locally. Ship to production with an already well-crafted set of observability signals.
That "playground" mindset is difficult to achieve when you're battling rate limits or shared-cluster quotas.
Privacy
One advantage of working with observability data on your localhost is that your data doesn't leave your machine by default. This means that you can use humanlog locally without having to review our security posture. Your data is safe on your disk.
Adopting a new observability cloud provider is a significant decision. Cloud vendors gain access to your sensitive operational data. Most businesses strictly prohibit sending production data to platforms that haven't undergone thorough security vetting. So when the production tools available to you don't meet your needs, you're left a bit out of luck. You can fetch the data locally and load it into general analytical tools and work from there, but this experience is not well crafted.
Humanlog bridges that gap. You don't need a vendor review to start exploring your data.
Sensitive logs and PII stay on your machine. No risk of accidentally exfiltrating HIPAA data or leaking credentials to a third-party SaaS.
The Fine Print
While your observability data does not leave your machine, things that do end up saved in our systems are:
| Type of data | Why |
|---|---|
| Queries | We save the queries that you execute on the UI in order to show you your query history. |
| Saved queries | When you use the saved query feature, the information you enter is saved in our system in order to bring it back to you. |
| Saved results | When you use the share results feature, the output data shown from your query is saved in our systems, along with the query, in order to power the share feature. |
Note that this list is for documentation purposes only and is not meant to be authoritative. Read our privacy policy for the legalese.
If you share your query results by using the share feature, the data in view will be uploaded to our cloud to make it visible to the people you want to share it with.
What's Next?
Need help or want to give feedback? Join our community channels.