# What Is the Entry Point for the Nitter Application?

> Discover the Nitter application's entry point at src/nitter.nim. Learn how configuration, routes, and runApp() launch the Jester HTTP server for Nitter.

- Repository: [Zed/nitter](https://github.com/zedeus/nitter)
- Tags: internals
- Published: 2026-09-04

---

**The Nitter application starts execution in `src/nitter.nim`, where the `when isMainModule:` block initializes configuration, registers routes, and calls `runApp()` to launch the Jester HTTP server.**

The open-source Twitter alternative Nitter, hosted in the `zedeus/nitter` repository, is built with the Nim programming language. Understanding the **entry point for the Nitter application** is essential for developers who want to customize the server, debug startup issues, or deploy custom instances. The initialization sequence begins in a single file that orchestrates configuration loading and HTTP server startup.

## Main Entry Point Location

The canonical entry point is **`src/nitter.nim`**. This file contains the `when isMainModule:` conditional compilation block that executes only when the file is compiled as the primary executable. Inside this block, the application invokes a strict sequence of initialization procedures before handing control to the web framework.

According to the `zedeus/nitter` source code, the critical startup sequence is:

```nim
when isMainModule:
  loadConfig()
  registerRoutes()
  runApp()

```

This structure ensures that configuration is parsed, URL routes are mapped to handlers, and the Jester HTTP server starts listening on the configured address and port.

## Initialization Flow and Key Components

The entry point delegates work to specialized modules across the codebase. Each function called in the `when isMainModule:` block corresponds to a specific subsystem.

### Configuration Loading

The **`loadConfig()`** procedure, defined in `src/config.nim`, executes first. It reads the [`nitter.conf`](https://github.com/zedeus/nitter/blob/main/nitter.conf) file (or environment variables) to populate global settings such as the server port, Redis connection details, and instance hostname. If configuration validation fails, the application exits before the HTTP server initializes.

### Route Registration

Next, **`registerRoutes()`** sets up the URL routing table. This function utilizes helpers from `src/routes/router_utils.nim` to map HTTP paths to their respective handler procedures. All API endpoints, RSS feeds, and user profile routes are registered at this stage, configuring the Jester router that will dispatch incoming requests.

### Server Execution

Finally, **`runApp()`** launches the Jester server loop. This function blocks the main thread and begins listening for connections. The `src/http_pool.nim` module is initialized during this phase to manage the HTTP client pool used for proxying requests to Twitter's internal API.

## Practical Startup Examples

Below are concrete methods for starting the application or modifying the entry point for development purposes.

### Starting Nitter from the Command Line

The standard method to launch the server uses Nimble to compile and run the entry point:

```bash
nimble run

```

This command compiles `src/nitter.nim` and immediately executes the resulting binary, triggering the full initialization sequence.

### Custom Entry Point for Testing

For integration tests or custom tooling, you can import the main module and override configuration before starting the server:

```nim
import src/nitter, src/config

proc startTestServer() =
  loadConfig("tests/config.test.conf")
  registerRoutes()
  runApp()

```

This pattern allows you to inject test-specific configuration without modifying the production entry point in `src/nitter.nim`.

### Adding Startup Hooks

To execute custom logic before the server accepts traffic, modify the `when isMainModule:` block directly:

```nim
when isMainModule:
  echo "Booting Nitter…"
  loadConfig()
  registerRoutes()
  # Your custom initialization here

  runApp()

```

## Summary

- The **entry point for the Nitter application** is located in **`src/nitter.nim`**.
- Execution begins inside the **`when isMainModule:`** block, which guards against running the server logic during library imports.
- The startup sequence follows a strict order: **`loadConfig()`** parses settings, **`registerRoutes()`** prepares the Jester router, and **`runApp()`** starts the HTTP listener.
- Key supporting files include **`src/config.nim`** (configuration), **`src/routes/router_utils.nim`** (routing logic), and **`src/http_pool.nim`** (HTTP client management).

## Frequently Asked Questions

### What file serves as the entry point for the Nitter application?

The file **`src/nitter.nim`** serves as the entry point. It contains the `when isMainModule:` block that executes the startup sequence only when the file is run as the primary executable, not when imported as a library.

### Which function actually starts the Nitter HTTP server?

The **`runApp()`** function starts the server. Called at the end of the initialization block in `src/nitter.nim`, it launches the Jester framework and begins listening on the configured TCP port for incoming HTTP requests.

### How can I run Nitter locally for development?

Run **`nimble run`** from the project root directory. This command compiles `src/nitter.nim` and executes the binary, automatically triggering `loadConfig()`, `registerRoutes()`, and `runApp()` to start a local instance.

### Where is the server configuration loaded during startup?

Configuration is loaded by the **`loadConfig()`** procedure defined in **`src/config.nim`**. This function is invoked immediately after the entry point executes, parsing the [`nitter.conf`](https://github.com/zedeus/nitter/blob/main/nitter.conf) file and environment variables before the HTTP server initializes.