# iKy: an OSINT platform that turns an email address into a profile

> iKy collects information about a subject from an email address or other selectors and shows the result in a visual interface, with 26 modules covering social networks, breach data, data brokers and search. It is a well organised piece of reconnaissance software, and it is explicit that some of its modules need your own browser session cookies to work at all.

**kennbroorg/iKy** — OSINT Project. Collect information from a mail. Gather. Profile. Timeline.

- Repository: https://github.com/kennbroorg/iKy
- Website: https://kennbroorg.gitlab.io/ikyweb/
- Stars: 988 · Forks: 158
- Language: Python
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/kennbroorg-iky

## A registry of 26 modules behind one query

The scope is stated in one sentence: iKy is an OSINT tool that collects information from an email address or other selectors and displays the results in a visual interface.

The module list is the substance, and it is routed through a single registry file, backend/module_registry.py, which means adding a data source is a matter of registering it rather than rewiring the application. Twenty six modules are listed in seven categories.

The social network group covers twitter, linkedin, instagram, tiktok, mastodon, twitch and reddit. The identity and username group is the widest, with github, gitlab, keybase, sherlock, socialscan, holehe, usersearch and skype. Then tinder and venmo under dating and payments, spotify under music, peopledatalabs, emailrep and fullcontact under reputation and data brokers, leaks, leaklookup, darkweb and hudsonrock under leaks and breaches, and a search module.

The distribution of categories tells you what kind of tool this is. Roughly a third is social media account discovery, which is the classic username enumeration problem, and a fifth is breach and data broker lookups, which is the part with the most legal weight. holehe, socialscan and sherlock are all grouped under identity and username lookups.

The readme also notes that the project collects and presents a timeline, which is the feature that makes the output more than a list of hits.

## Four services, and the queue that keeps them honest

The architecture table is short and worth reading carefully, because it explains why the tool needs Redis and a task queue at all.

The backend is FastAPI 0.115 with Celery 5.6 on port 5000. The front end is Angular 21 served by nginx on port 4300. Redis 7 is exposed to the host on 56379, and Tor runs as a SOCKS5 proxy, internal only, for the darkweb module.

Redis is not a cache here, it is the message broker and the result store. The compose file wires the backend to it with a broker URL and a result backend URL, both pointing at the same Redis database, and the host name resolves to the Redis service inside the compose network.

That architecture is a direct consequence of what the modules do. A single lookup against a data broker or a set of username enumerations can take a long time, and some of them wait for a browser to render. A synchronous HTTP request from the browser to the API would time out, so the work is handed to Celery workers and the front end polls for results. It is the right shape for the problem, and it is also why the tool needs Docker or a careful native setup rather than a pip install.

The Tor service is a single container, pinned by digest rather than by a tag, and the comment explains why: the image has no semantic tags, and a floating tag is discouraged for reproducible builds. Its proxy URL is configurable through an environment variable, and it is exposed internally rather than published on a host port.

## Running it: two commands, then a browser

The quick start is short, and the task runner does most of the work.

```shell
git clone https://gitlab.com/kennbroorg/iKy.git
cd iKy
just build
just up
```

Then you open your browser at localhost on port 4300. To stop everything, the down recipe runs the compose teardown:

```shell
just down
```

The readme is careful about what the up recipe actually starts. It launches the backend, the front end and Redis, and no other services by default. That detail matters because the compose file also defines a legacy front end service, and the justfile notes that the up recipe excludes it and that you should start it explicitly if you need it. There is also an init recipe that copies the default API key file into place, and it exists to stop Docker from creating a directory where a file is expected, which is a small annoyance that would otherwise be confusing on a first run.

There is a native path for people who cannot run Docker. In that mode Caddy serves the pre-built front end while Redis, Celery and Uvicorn run as local processes, and the host needs a Redis server, Python 3.12, curl and tar, with Caddy downloaded automatically. The recipes are:

```shell
just setup
just up-native
```

Two details in the native mode are worth knowing in advance. The front end is pulled from the latest GitHub release, so there is no Node build step, and Tor is not launched in native mode, which means only the darkweb module is affected.

## The API key table tells you which modules actually work

The readme includes a table of the fields the application expects, taken from a default key file in the backend, and the status column is the most useful thing in the whole document.

Most entries are marked as working. PeopleDataLabs, Emailrep and Leaklookup are free API keys, Spotify and Twitch need a client id and secret, Google Programmable Search needs a key and a search engine id, and Brave needs its own key.

Three entries are not working, and the readme says so rather than hiding them. Instagram is under revision. Fullcontact is discontinued. HaveIBeenPwned is discontinued, even though the module list still contains a leaks module built on other sources.

That pattern, working, under revision, discontinued, is the honest summary of the OSINT tool ecosystem. The upstream services change, their pricing changes and their terms change, and a tool that aggregates twenty of them is permanently exposed to that. A module that works today can be broken by a change on someone else's side with no change to the project at all.

The keys are entered in the settings panel after the application loads in the browser, and the file is mounted into the container from the host, so you can manage them outside the container if you prefer.

## Session cookies are what the social modules run on

Three modules are marked as needing cookies rather than a service token: LinkedIn, Twitter and TikTok. The readme explains why, and it is not a design shortcut, it is the nature of the sites.

Those platforms will not return profile data to an unauthenticated client, so the tool has to act as you. The cookies come from your own browser, either exported with an extension such as Cookie-Editor into a JSON file and imported, or extracted automatically from the local browser by a recipe, with the browser closed first.

```shell
just cookies-import linkedin ~/Downloads/linkedin_cookies.json
```

The storage detail is the one to notice. Cookies are written to a cookies directory in the backend, mounted into the container, and they persist across restarts. The readme flags them as personal session tokens and says not to share them or commit them, and notes that the directory is git-ignored. That is correct advice and it is also the weakest point in the whole design, because a session cookie for a logged-in account is exactly as sensitive as the account, and a directory of them on a machine that is also running breach lookups and a Tor proxy is not a place you want to be casual about.

The legacy field names are kept for compatibility, so the LinkedIn entry accepts the current cookie field as well as two older ones, which tells you the project has been through a couple of platform changes.

## A dependency list that shows the fragility

The requirements file is long, and one entry in it is the most informative line in the repository.

The comment says that a version of the twikit library has been broken since March 2026 because of a change in how it indexes a key, and the requirement points at a fork of the project on GitHub rather than at the published package. A library pinned to a personal fork because the upstream release is broken is a maintenance signal, and it is the kind of thing that tells you a project is doing its best to keep working against moving targets.

The rest of the list explains the scope. There are two HTTP stacks, httpx with HTTP 2 support and requests with socks support, and two scraping tools, cloudscraper and cfscrape, which exist to get past the bot protection on some sites. Beautiful Soup and lxml for parsing, aiohttp and requests-futures for concurrency, playwright for browser automation, and instaloader and TikTokApi for the two platforms with dedicated clients. Tor support comes from torrequest and PySocks, and geopy and the geocoding tools cover location data.

There is also a set of data services, spotipy for Spotify, tweepy for Twitter, emailrep, peopledatalabs, twitch-python, youtube-transcript-api and the Google API client, plus analysis libraries including thefuzz for fuzzy matching, langdetect for language detection and vaderSentiment for sentiment.

The stack is the argument for and against the project at once. It has everything needed to do the job, and it has a lot of surface area through which an upstream change can break the tool.

## Licence, branch and the release naming

Three administrative details close the picture.

The licence is GPL-3.0, which is a good fit for a research and investigation tool, since it guarantees that anyone who improves the modules can share the improvement. The default branch is iKy, which is the older style of branch naming for a project that predates the current conventions.

The releases are named after the front end rather than the whole application, with a frontend-v1.0.0 published on 2026-06-02 and frontend-v1.0.1 on 2026-06-10, plus a floating frontend-latest tag. That naming is consistent with the architecture, where the front end is a separately built artefact pulled from a GitHub release by the compose file, with a version argument that can be pinned to a specific build or left as latest.

The compose file also shows the mechanism for reproducibility: the front end version is an argument, the Tor image is pinned by digest, and the Redis image is a versioned alpine tag. The backend image is built from a Dockerfile in the install directory.

The last push to the repository was on 2026-10-10 and the project is not archived. The repository is hosted on GitLab rather than GitHub, with a Spanish readme alongside the English one, a contribution guide, a credits file and a pre-commit configuration, and the readme points to the issue tracker for problems.

## Conclusion

iKy suits an investigator who wants one interface over many data sources, with a queue that can take long running lookups, and who is prepared to supply their own API keys and, for the social modules, their own session cookies. It is a poor fit if you cannot obtain keys for the services it queries, if you need results you are legally barred from collecting, or if you want a tool that will not break when an upstream library changes. Before you rely on it, read the module status table in the readme, keep the cookie directory out of version control as the project asks, and check the requirements file, because a pinned fork of a library is a maintenance signal you should not ignore.

## FAQ

### How do I run iKy?

Clone the repository, then run just build and just up, and open your browser at localhost on port 4300. The up recipe starts the backend, the front end and Redis. If you cannot run Docker, just setup and just up-native run it locally with Caddy, Redis, Celery and Uvicorn, and you need a Redis server, Python 3.12, curl and tar on the host.

### Which iKy modules need my own API keys?

You enter them in the settings panel after the application loads. PeopleDataLabs, Emailrep, Leaklookup, Spotify, Twitch, Google Programmable Search and Brave all need keys, most of them free, and the readme links a wiki page per service for how to obtain them. Instagram is under revision, and Fullcontact and HaveIBeenPwned are marked discontinued.

### Why do the LinkedIn, Twitter and TikTok modules need browser cookies?

Those platforms do not return profile data to an unauthenticated client, so the module has to act as you using a session cookie. You can import a JSON export from an extension such as Cookie-Editor, or let a recipe extract the cookies from your local browser. The readme stresses that they are personal session tokens, must not be shared or committed, and the cookies directory is git-ignored.

### Does iKy need Tor to work?

No. Tor is launched as a SOCKS5 proxy in the Docker setup and is used by the darkweb module for onion lookups, but in native mode it is not started, so only that module is affected. The compose file also lets you point the proxy at a different address through an environment variable.

## Sources

- [kennbroorg/iKy on GitHub](https://github.com/kennbroorg/iKy)
- [License: GPL-3.0](https://github.com/kennbroorg/iKy/blob/iKy/LICENSE)
- [Project website](https://kennbroorg.gitlab.io/ikyweb/)
- [README](https://github.com/kennbroorg/iKy/blob/iKy/README.md)
- [Releases](https://github.com/kennbroorg/iKy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kennbroorg-iky