Logflare and the case for bringing your own log backend

Bring your own BigQuery, and let the schema follow

Logflare is a service for streaming logs to a central place and tailing them in a browser, and the thing that makes it different is stated in the README as bring your own backend. You provide your BigQuery credentials, and the service streams your logs into your BigQuery table while automatically managing the schema.

That last clause is the whole product. Structured logging has a schema problem, and it is the reason many teams give up on centralised logging. Every new log field is a schema change, and schema changes in an analytics backend mean either a migration or a table that slowly turns into a dumping ground of loosely typed columns. A service that watches the incoming log shapes and maintains the table schema for you removes that work, and it does so in a warehouse the team already owns and already knows how to query.

The pitch in the repository description is economic rather than technical, that you will never get surprised by a logging bill again. That follows from the architecture. If the logs land in your BigQuery dataset, you pay BigQuery for storage and for the queries you run, and you can set budgets and partitions on the side you already administer, rather than paying a vendor's ingest price for traffic you did not choose to send.

The audience is a team running many services, possibly on many runtimes, that wants one searchable log destination and one bill it can predict. The team behind it, Logflare, is now part of Supabase, which the README states plainly and which matters for anyone thinking about a long term dependency on the project.

An Elixir service with Rust native extensions

The primary language is Elixir, and the repository is an OTP application in the usual Elixir layout, with mix.exs, mix.lock, lib/, config/, priv/, rel/, test/ and bench/. A .tool-versions file pins the toolchain versions, and the Docker build shows what they are, with Elixir 1.19.5, Erlang/OTP 27.3.4.6 and a Debian trixie base.

The interesting part is the native/ directory. The Cargo workspace at the root declares three Rust crates, native/arrowipc_ex, native/sqlparser_ex and native/mapper_ex, which tells you the shape of the performance work. One crate speaks the Arrow IPC protocol, which is the columnar exchange format used to move data between compute and analytics systems, and in a project whose job is to land data in BigQuery that is not an incidental dependency. Another parses SQL, and a third maps log fields onto the target schema, which is the piece that makes automatic schema management possible rather than merely advertised.

The Dockerfile shows how the two languages are built together, and it contains a comment worth reading. Native extensions are compiled before the application source is copied in, so ordinary Elixir changes can reuse the expensive architecture specific Rust build. The comment goes further, noting that Cargo freshness checks are kept independent of checkout timestamps so a cached target stays reusable after the full source tree is copied, and that Rustler invokes cargo rustc during mix release, so using plain cargo build here would create different final crate units and make Rustler compile every NIF again. That is the level of detail a project reaches when its build cache is part of its developer experience.

The release profile is tuned in the same spirit, with CARGO_PROFILE_RELEASE_LTO set to thin and the code generation units set to 1.

The compose file describes the deployment shape

The repository carries six compose files, for the plain local setup and for the GCP, MinIO, PostgreSQL and pglogical variants, and the main one is short enough to read as a description of the system.

  logflare:
    build:
      dockerfile: ./Dockerfile
    ports:
      - "4000:4000"
      - "50051:50051"
    hostname: 127.0.0.1
    volumes:
      - type: bind
        source: ${PWD}/.single_tenant_bq.env
        target: /tmp/.secrets.env
        read_only: true

Two ports are published. 4000 is the service itself, and 50051 is annotated in the file as being for OTLP ingestion, which is the OpenTelemetry protocol path. That tells you that the primary way logs arrive is over OTLP, which is the most useful fact in the file for anyone planning an adoption.

The volumes are the other half of the story. Two bind mounts are marked read only, the single tenant BigQuery environment file mounted at /tmp/.secrets.env and the gcloud.json file mounted into the release directory. Both are credentials, and the read only flag is what stops the container from rewriting them.

The rest of the stack is the supporting cast. A postgres:15 service with a logflare_dev database and a setup.sql mounted into the init directory holds the service's own state, a filebeat service from the Elastic beats image listens on port 8000 with a configuration mounted in, and there are separate base and runner images built from Dockerfile.base and Dockerfile.runner, so the build can be split into a toolchain image and a runtime image.

Clients live in their own repositories

The integrations table is where the project reveals that it is really a family of pieces rather than one application.

For telemetry in, there is an OpenTelemetry integration documented on the docs site, and the repository carries two runnable examples, a Cloudflare Worker using OTEL and an OpenTelemetry Collector configuration. The collector example matters, because a collector is how a team routes logs from many sources into one place with rules about what to send and what to drop.

For platform log sources, there is a Vercel integration linked from the table, a Fly log shipper at Logflare/fly-log-shipper, and a GitHub Action.

For application logging there are five separate client libraries, and the pattern is consistent: for JavaScript, a pino transport and a winston transport, for Elixir, a logger backend and an agent, and for Erlang, a logflare_erl library. Each of those is a small package that formats and ships logs, and keeping them out of this repository means the core service can change its protocol without forcing a coordinated release of every client.

That design has a cost, and it is the ordinary one. A team that adopts Logflare ends up depending on several repositories rather than one, each with its own release cadence, and the compatibility between a client and the service is a thing you now have to track. The upside is that the clients are small enough to read, and the integrations for a platform such as Vercel can change without a core release.

A make driven workflow that checks your gcloud

The Makefile is where the developer experience is written down, and a few of its details are worth calling out.

The targets are conventional for an Elixir project. The test target starts the Erlang port mapper daemon and runs mix test, with a test.failed variant that reruns only the failures and a test.only variant, and a compile.check target that recompiles with compiler options to expose warnings. The help target simply cats DEVELOPMENT.md, which keeps the documentation and the tooling in one place.

The tool check is the interesting part. The Makefile declares that docker, git and gcloud are required, and the check-tools target runs through them and prints a warning for each one that is not on the path. The reason gcloud is on the list is in the variables at the top of the file, with a location, a keyring, a key name and a project, and with image tags built from the project, the component and a short commit SHA, plus a version read from the VERSION file.

There is also a version manager detection block, with mise preferred over asdf, and the reshim step defined for whichever is present. That is a small thing that says the project expects people to work on it from a fresh checkout without a long setup.

One variable deserves attention for anyone running this in a shared environment, a flag for Supabase mode, off by default. It signals that the same codebase is used inside a larger product and standalone, and that the two deployments are not configured identically.

Apache-2.0, a weekly release line, and a change of owner

The licence is Apache 2.0, with the text in LICENSE.md at the root of the repository, and the project publishes its releases on GitHub with the v prefix visible in the tag names.

The release cadence is fast and consistent. v1.53.1 was published on 2026-10-14, v1.53.0 on 2026-10-08 and v1.52.0 on 2026-10-05, so a minor version every week or so during that month, with patch releases on top. The repository is not archived, and the last push was on 2026-10-19, five days after the newest tag. A VERSION file at the root feeds the image tags, so the version you see in a running container matches the release you built.

The governance point is the one to think about rather than the cadence. The README states that Logflare is now a part of Supabase, and the compose images are tagged supabase/logflare. For a project whose whole pitch is bringing your own backend, being part of a larger platform company changes the questions you should ask. Where the roadmap goes, what the hosted service at logflare.app commits to, and what happens to the open source project if the two priorities diverge, are all things the README does not answer, and they are reasonable things to ask before a team depends on it for a log pipeline.

The support contacts are given in the README too, both [email protected] and [email protected], which is the same question asked in two places.

Editorial conclusion

Adopt Logflare if you run on Google Cloud, want a single searchable place for logs from many runtimes, and prefer to pay BigQuery's storage and query costs rather than a per-gigabyte logging vendor. Do not adopt it if your estate is not on BigQuery, since the bring your own backend idea is the product, and treat the Supabase ownership change as a governance question to settle before a long term dependency. Verify three things first: that the schema management behaves as you expect for your log shapes, since automatic schema management is the feature that replaces the usual maintenance work, that the OpenTelemetry path is the ingestion route you intend to use, with the OTLP port exposed, and how the single tenant environment files are supplied, since the compose file expects credentials mounted read only. The last push was on 2026-10-19 and the newest release is v1.53.1 from 2026-10-14.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Logflare/logflare on GitHub
3. Project website
4. README
5. Releases