Enola: a Go tool for finding social accounts by username

What a run actually checks

The tool is described as a modern shiny command line tool written with Go that helps you hunt down social media accounts by username across social networks, and it is framed as the sister of Sherlock, the well known username search project, with a different name and a different implementation rather than a fork of the same code. The core operation is small. You give it a username, it queries the catalogue of supported sites, and it reports for each one whether an account was found. The output is a record per site with a name, a URL and a found flag, which is the shape you would want for piping into something else. The documentation also names an example of a demo recording and the repository holds it. What the tool does not do is authenticate, and that is the boundary worth understanding before you build anything on it, because the difference between an account that exists and an account you can reach is exactly the difference a search tool cannot bridge.

Installing it, and the Go version requirement

Installation is a single go install with a stated minimum of Go 1.26:

go install github.com/theyahya/enola/cmd/enola@latest

The command lives under a cmd directory, so the binary path follows the usual Go layout and the tool is a normal module install rather than something you fetch a release archive for. The version floor is high. The module file asks for Go 1.26.3, which is a recent release, and that has a knock-on effect for the container build, because the Dockerfile still compiles from an older Go image, a 1.24 Alpine base, which means the image and the module file disagree about the toolchain. It is a small inconsistency, but it is the kind of thing that produces a confusing error rather than an obvious one. The Docker route is documented as well, with a build command and a run command:

docker build -t enola .

docker run --rm -it enola {username}

The container image runs the tests during the build with CGO disabled, which is a nice touch, since a build that fails on a broken test is a build that never produces a broken image.

The command line surface

The usage section is three lines, which is a good sign for a tool with a narrow job:

enola {username}
enola {username} --site twitter
enola {username} --output ./results.json

The first form checks the username against the whole catalogue. The second restricts the check to a single named site, which is what you want when you already know where to look and want a fast answer, or when you are testing a detector. The third writes the results to a file rather than to the terminal, and the output option is what turns the tool from something you read into something you pipe. The underlying terminal interface is built on the Charm libraries, with bubbletea and bubbles for the interactive parts and lipgloss for styling, and the dependency list confirms the versions, with the second generation of each. That is a deliberate choice rather than a plain print, and it means the tool renders a progress view while it queries, which matters when the catalogue is large and some sites are slow to answer.

The library interface and its options

The same functionality is available as a Go package, and the example is short enough to read as a specification:

ctx := context.Background()
e, err := enola.New()
if err != nil {
    log.Fatal(err)
}

results, err := e.SetSite("twitter").Check(ctx, "username")
if err != nil {
    log.Fatal(err)
}

for r := range results {
    fmt.Println(r.Name, r.URL, r.Found)
}

The shape is a builder with a chainable call, where SetSite narrows the search and Check takes a context and a username, and the results come back as a channel that you range over, so the caller streams them rather than waiting for the whole run. Three options are documented, one for supplying your own HTTP client, one for setting the concurrency, and one for supplying the data. The HTTP client option is the important one for anything beyond a quick check, because it is how you control timeouts, proxies, redirect policy and user agent, and a tool that makes dozens of outbound requests will otherwise use whatever the Go default is. The data option presumably lets you point the tool at a different catalogue rather than the bundled one, and the repository contains a data.json at the root, which is where the site definitions live.

Detection strategies are pluggable, and that is the extension point

The contributing section describes how a new site is added, and the mechanism is a registry rather than a switch statement, which is the right design for a tool whose site list changes weekly. You create a file in the internal checker directory that implements the detector interface, and it registers itself in an init function through a register call with a type name. The init-based registration means a new detector file is picked up by the import of its package, so adding a site is a matter of adding a file and the wiring happens on its own. The repository layout backs this up, with the internal directory holding the checker and the surrounding machinery, and separate top level files for the core entry point, the options, the regular expression handling, the result type, the website type and the errors. The presence of a regex module and the dependency on a regular expression library with backtracking support tells you that a detector can match a site's response body against a pattern rather than only doing a status code check, which is how the more careful sites are handled, and the data file at the root is what maps a site name to its URL pattern.

The release story and the licence

The release history is short and shows a project that reached a stable point recently. The most recent releases are v1.0.0 and 1.0.0, both on 2026-07-10, with v0.4.2 from 2026-05-28 before them, and the last push was on the same day as those tags. A 1.0.0 marker is the first sign that the author considers the interface settled, which for a library that others are encouraged to embed is the important milestone, and the library usage example in the documentation is written against that version. The licence is MIT, and the software is released under it. The repository also carries a changelog, a commit message convention file, a GitHub directory and a Dockerfile, and the module depends on the standard concurrency primitives, so the parallel checking across sites is built on the standard library rather than on a bespoke pool. The last thing worth knowing is what the tool is for, which the documentation is careful about, since the sister project reference frames it as a presence check rather than an investigation tool, and the results it gives you are a starting point for asking better questions rather than an answer to one.

Editorial conclusion

Enola is a good fit for a security researcher or a brand manager who wants a fast, scriptable presence check across many platforms without maintaining a list of URLs by hand, and the library interface makes it straightforward to embed in a wider pipeline. It is the wrong tool if you need to know that an account exists behind a login, because a detector answers a narrower question than that, and it is the wrong tool if you need a result you can rely on for evidence, because the output reflects what a public page returned at that moment. It is also the wrong tool if you want the same detection logic as the tool it is named after, since the project positions itself as a separate implementation rather than a drop-in replacement. Before adopting it, look at how a detection strategy is written, since adding a site means implementing the detector interface and registering it, and note the version skew in the build, where the module asks for a recent Go release while the container image is built from an older one. The project is MIT licensed, the last push was on 2026-07-10, and the current release is v1.0.0 from the same day.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. TheYahya/enola on GitHub