ida-pro-mcp Documentation

AI-powered reverse engineering assistant that bridges IDA Pro with language models through MCP.

10,711 stars Python Python 1 file · ~12,970 tokens #ai#aiagent#binary-analysis#ida-plugin#ida-pro#mcp#mcp-server#modelcontextprotocol
RAW Doc

Technical Documentation: mrexodia/ida-pro-mcp

ℹ️ Provenance: Hybrid Fusion: mrexodia/ida-pro-mcp + mrexodia/docs · CodeWiki Reference · Recency: Active (< 180 days)

1. Project Overview & Quickstart (mrexodia/ida-pro-mcp)

IDA Pro MCP

Simple MCP Server to allow vibe reversing in IDA Pro.

https://github.com/user-attachments/assets/6ebeaa92-a9db-43fa-b756-eececce2aca0

The binaries and prompt for the video are available in the mcp-reversing-dataset repository.

Prerequisites

Note: This requires having idalib activated globally and uv installed:

bash
# windows
uv run "C:\Program Files\IDA Professional 9.3\idalib\python\py-activate-idalib.py"
# macos
uv run "/Applications/IDA Professional 9.3.app/Contents/MacOS/idalib/python/py-activate-idalib.py"
# linux
uv run "/path/to/idapro-9.3/idalib/python/py-activate-idalib.py"

Installation (Claude Code)

To install the latest IDA Pro MCP in Claude Code:

bash
claude plugin marketplace add mrexodia/claude-marketplace
claude plugin uninstall ida-pro-mcp@mrexodia
claude plugin install ida-pro-mcp@mrexodia

Installation (Codex)

To install the latest IDA Pro MCP in Codex:

bash
codex plugin marketplace add mrexodia/codex-marketplace
codex plugin remove ida-pro-mcp@mrexodia
codex plugin add ida-pro-mcp@mrexodia

Installation (Kimi Code)

To install the latest IDA Pro MCP in Kimi Code, run this slash command in the chat:

text
/plugins install https://github.com/mrexodia/ida-pro-mcp/tree/main
/reload

This installs the idalib MCP server and the idapython skill. Plugins are copied to
$KIMI_CODE_HOME/plugins/managed/, so uv must be on your PATH. The first session after
installing is slower, because uv resolves the dependencies before the server responds.

Installation (GUI)

Note: the MCP plugin is no longer recommended and will eventually be deprecated. Use idalib-mcp instead.

If you want to configure the MCP server manually from the IDA GUI:

sh
pip uninstall ida-pro-mcp
pip install https://github.com/mrexodia/ida-pro-mcp/archive/refs/heads/main.zip

Configure the MCP servers and install the IDA Plugin:

text
ida-pro-mcp --install

Important: Make sure you completely restart IDA and your MCP client for the installation to take effect. Some clients (like Claude) run in the background and need to be quit from the tray icon.

Prompt Engineering

LLMs are prone to hallucinations and you need to be specific with your prompting. For reverse engineering the conversion between integers and bytes are especially problematic. Below is a minimal example prompt, feel free to start a discussion or open an issue if you have good results with a different prompt:

md
Your task is to analyze a crackme in IDA Pro. You can use the MCP tools to retrieve information. In general use the following strategy:

- Inspect the decompilation and add comments with your findings
- Rename variables to more sensible names
- Change the variable and argument types if necessary (especially pointer and array types)
- Change function names to be more descriptive
- If more details are necessary, disassemble the function and add comments with your findings
- NEVER convert number bases yourself. Use the `int_convert` MCP tool if needed!
- Do not attempt brute forcing, derive any solutions purely from the disassembly and simple python scripts
- Create a report.md with your findings and steps taken at the end
- When you find a solution, prompt to user for feedback with the password you found

This prompt was just the first experiment, please share if you found ways to improve the output!

Another prompt by @can1357:

md
Your task is to create a complete and comprehensive reverse engineering analysis. Reference AGENTS.md to understand the project goals and ensure the analysis serves our purposes.

Use the following systematic methodology:

1. **Decompilation Analysis**
   - Thoroughly inspect the decompiler output
   - Add detailed comments documenting your findings
   - Focus on understanding the actual functionality and purpose of each component (do not rely on old, incorrect comments)

2. **Improve Readability in the Database**
   - Rename variables to sensible, descriptive names
   - Correct variable and argument types where necessary (especially pointers and array types)
   - Update function names to be descriptive of their actual purpose

3. **Deep Dive When Needed**
   - If more details are necessary, examine the disassembly and add comments with findings
   - Document any low-level behaviors that aren't clear from the decompilation alone
   - Use sub-agents to perform detailed analysis

4. **Important Constraints**
   - NEVER convert number bases yourself - use the int_convert MCP tool if needed
   - Use MCP tools to retrieve information as necessary
   - Derive all conclusions from actual analysis, not assumptions

5. **Documentation**
   - Produce comprehensive RE/*.md files with your findings
   - Document the steps taken and methodology used
   - When asked by the user, ensure accuracy over previous analysis file
   - Organize findings in a way that serves the project goals outlined in AGENTS.md or CLAUDE.md

Live stream discussing prompting and showing some real-world malware analysis:

Tips for Enhancing LLM Accuracy

Large Language Models (LLMs) are powerful tools, but they can sometimes struggle with complex mathematical calculations or exhibit "hallucinations" (making up facts). Make sure to tell the LLM to use the int_convert MCP tool and you might also need math-mcp for certain operations.

Another thing to keep in mind is that LLMs will not perform well on obfuscated code. Before trying to use an LLM to solve the problem, take a look around the binary and spend some time (automatically) removing the following things:

  • String encryption
  • Import hashing
  • Control flow flattening
  • Code encryption
  • Anti-decompilation tricks

You should also use a tool like Lumina or FLIRT to try and resolve all the open source library code and the C++ STL, this will further improve the accuracy.

Transports & Headless MCP

You can run an SSE server to connect to the user interface like this:

sh
uv run ida-pro-mcp --transport http://127.0.0.1:8744/sse

After installing idalib you can also run a headless MCP server. You can start with an initial binary:

sh
uv run idalib-mcp --host 127.0.0.1 --port 8745 path/to/executable

Or start without a binary and open arbitrary files later with idb_open(...):

sh
uv run idalib-mcp --host 127.0.0.1 --port 8745

For stdio-based clients, use:

sh
uv run idalib-mcp --stdio

Database workers are persistent: each one runs as a detached process that
outlives the supervisor that spawned it. When a new supervisor (over stdio
or HTTP) calls idb_open for a binary that is already open under a worker
on this host, the supervisor adopts that worker transparently — there is
no separate "shared" mode to enable. Workers self-exit when no request has
hit them for an idle interval.

Note: The idalib feature was contributed by Willi Ballenthin.

Headless idalib Session Model

idalib-mcp is a supervisor that keeps each open database in its own idalib worker process. Workers register themselves in a host-local discovery directory and outlive the supervisor that spawned them; any subsequent supervisor that wants the same path adopts the running worker. A worker self-exits when no request has hit it for its idle TTL (default 1 hour). Call idb_close to release a worker eagerly (freeing a slot toward --max-workers), adopted GUI/worker instances are detached rather than killed.

idb_open picks the backend via its mode parameter:

  • prefer_headless (default): spawn an idalib worker (or adopt one that already has the file open).
  • force_headless: same, but never adopt a running GUI even if one has the file.
  • prefer_gui: adopt a running GUI for the file; otherwise spawn an idalib worker.
  • force_gui: adopt a running GUI for the file; otherwise launch a new IDA GUI process.

Every tool call must carry an explicit database argument. There is no implicit "current database" — callers name the session they want to operate on.

sh
uv run idalib-mcp --stdio --max-workers 4

Typical flow:

python
idb_open("/path/to/binary_a.exe", preferred_session_id="binary_a")
idb_open("/path/to/library.dll", preferred_session_id="library")

decompile("main", database="binary_a")
xrefs_to("ImportantExport", database="library")

database must be the session ID returned by idb_open (or shown in idb_list); filenames and paths are not accepted.

Management tools

  • idb_open(input_path, mode="prefer_headless", run_auto_analysis=True, build_caches=True, init_hexrays=True, preferred_session_id=""): Open a binary, warm up subsystems (strings cache, Hex-Rays), and return its session ID. If a worker or GUI for this path is already running on the host, that instance is adopted and preferred_session_id is ignored.
  • idb_list(): List open sessions and running GUI IDA instances. Each entry has adopted (True if this supervisor manages it, False for GUIs/workers discovered but not yet opened via idb_open), backend (worker or gui), is_active, and process IDs.
  • idb_close(database, save=True): Save (optionally), unregister the session, and terminate its owned worker, freeing a slot toward --max-workers. Adopted GUI/worker instances are detached, not killed.
  • idb_save(session_id, path=""): Save a session's IDB to disk. Forwarded as a regular worker tool (database= injected) — same signature in both backends.
  • Per-database health: call server_health(database=) (forwarded). idb_list() reports is_active from the supervisor's TCP/RPC probe.

Worker controls:

  • --max-workers N: maximum simultaneous database workers (0 = unlimited, default 4).
  • IDA_MCP_MAX_WORKERS: environment default for --max-workers.

MCP Resources

Resources represent browsable state (read-only data) following MCP's philosophy.

Core IDB State:

  • ida://idb/metadata - IDB file info (path, arch, base, size, hashes)
  • ida://idb/segments - Memory segments with permissions
  • ida://idb/entrypoints - Entry points (main, TLS callbacks, etc.)

UI State:

  • ida://cursor - Current cursor position and function
  • ida://selection - Current selection range

Type Information:

  • ida://types - All local types
  • ida://structs - All structures/unions
  • ida://struct/{name} - Structure definition with fields

Lookups:

  • ida://import/{name} - Import details by name
  • ida://export/{name} - Export details by name
  • ida://xrefs/from/{addr} - Cross-references from address

Core Functions

  • lookup_funcs(queries): Get function(s) by address or name (auto-detects, accepts list or comma-separated string).
  • int_convert(inputs): Convert numbers to different formats (decimal, hex, bytes, ASCII, binary).
  • list_funcs(queries): List functions (paginated, filtered).
  • list_globals(queries): List global variables (paginated, filtered).
  • imports(offset, count): List all imported symbols with module names (paginated).
  • decompile(addr): Decompile function at the given address.
  • disasm(addr): Disassemble function with full details (arguments, stack frame, etc).
  • xrefs_to(addrs): Get all cross-references to address(es).
  • xrefs_to_field(queries): Get cross-references to specific struct field(s).
  • callees(addrs): Get functions called by function(s) at address(es).

Modification Operations

  • add_bookmark(addr, name, prefix): Add or replace the IDA bookmark at an address; set prefix="" for no prefix.
  • set_comments(items): Set comments at address(es) in both disassembly and decompiler views.
  • patch_asm(items): Patch assembly instructions at address(es).
  • declare_type(decls): Declare C type(s) in the local type library.
  • define_func(items): Define function(s) at address(es). Optionally specify end for explicit bounds.
  • define_code(items): Convert bytes to code instruction(s) at address(es).
  • undefine(items): Undefine item(s) at address(es), converting back to raw bytes. Optionally specify end or size.

Memory Reading Operations

  • get_bytes(addrs): Read raw bytes at address(es).
  • get_int(queries): Read integer values using ty (i8/u64/i16le/i16be/etc).
  • get_string(addrs): Read null-terminated string(s).
  • get_global_value(queries): Read global variable value(s) by address or name (auto-detects, compile-time values).

Stack Frame Operations

  • stack_frame(addrs): Get stack frame variables for function(s).
  • declare_stack(items): Create stack variable(s) at specified offset(s).
  • delete_stack(items): Delete stack variable(s) by name.

Structure Operations

  • read_struct(queries): Read structure field values at specific address(es).
  • search_structs(filter): Search structures by name pattern.

Debugger Operations (Extension)

Debugger tools are hidden by default. Enable with ?ext=dbg query parameter:

text
http://127.0.0.1:13337/mcp?ext=dbg

Control:

  • dbg_start(): Start debugger process.
  • dbg_exit(): Exit debugger process.
  • dbg_continue(): Continue execution.
  • dbg_run_to(addr): Run to address.
  • dbg_step_into(): Step into instruction.
  • dbg_step_over(): Step over instruction.

Breakpoints:

  • dbg_bps(): List all breakpoints.
  • dbg_add_bp(addrs): Add breakpoint(s).
  • dbg_delete_bp(addrs): Delete breakpoint(s).
  • dbg_toggle_bp(items): Enable/disable breakpoint(s).

Registers:

  • dbg_regs(): All registers, current thread.
  • dbg_regs_all(): All registers, all threads.
  • dbg_regs_remote(tids): All registers, specific thread(s).
  • dbg_gpregs(): GP registers, current thread.
  • dbg_gpregs_remote(tids): GP registers, specific thread(s).
  • dbg_regs_named(names): Named registers, current thread.
  • dbg_regs_named_remote(tid, names): Named registers, specific thread.

Stack & Memory:

  • dbg_stacktrace(): Call stack with module/symbol info.
  • dbg_read(regions): Read memory from debugged process.
  • dbg_write(regions): Write memory to debugged process.

Advanced Analysis Operations

  • py_eval(code): Execute arbitrary Python code in IDA context (returns dict with result/stdout/stderr, supports Jupyter-style evaluation).
  • analyze_funcs(addrs): Comprehensive function analysis (decompilation, assembly, xrefs, callees, callers, strings, constants, basic blocks).
  • find_regex(queries): Search strings with case-insensitive regex (paginated).
  • find_bytes(patterns, limit=1000, offset=0): Find byte pattern(s) in binary (e.g., "48 8B ?? ??"). Max limit: 10000.
  • find_insns(sequences, limit=1000, offset=0): Find instruction sequence(s) in code. Max limit: 10000.
  • find(type, targets, limit=1000, offset=0): Advanced search (immediate values, strings, data/code references). Max limit: 10000.

Control Flow Analysis

  • basic_blocks(addrs): Get basic blocks with successors and predecessors.

Type Operations

  • set_type(edits): Apply type(s) to functions, globals, locals, or stack variables.
  • infer_types(addrs): Infer types at address(es) using Hex-Rays or heuristics.

Export Operations

  • export_funcs(addrs, format): Export function(s) in specified format (json, c_header, or prototypes).

Graph Operations

  • callgraph(roots, max_depth): Build call graph from root function(s) with configurable depth.

Batch Operations

  • rename(batch): Unified batch rename operation for functions, globals, locals, and stack variables (accepts dict with optional func, data, local, stack keys).
  • patch(patches): Patch multiple byte sequences at once.
  • put_int(items): Write integer values using ty (i8/u64/i16le/i16be/etc).

Key Features:

  • Type-safe API: All functions use strongly-typed parameters with TypedDict schemas for better IDE support and LLM structured outputs
  • Batch-first design: Most operations accept both single items and lists
  • Consistent error handling: All batch operations return [{..., error: null|string}, ...]
  • Cursor-based pagination: Search functions return cursor: {next: offset} or {done: true} (default limit: 1000, enforced max: 10000 to prevent token overflow)
  • Performance: Strings are cached with MD5-based invalidation to avoid repeated build_strlist calls in large projects

Development

Adding new features is a super easy and streamlined process. All you have to do is add a new @tool function to the modular API files in src/ida_pro_mcp/ida_mcp/api_*.py and your function will be available in the MCP server without any additional boilerplate! Below is a video where I add the get_metadata function in less than 2 minutes (including testing):

https://github.com/user-attachments/assets/951de823-88ea-4235-adcb-9257e316ae64

To test the MCP server itself:

sh
npx -y @modelcontextprotocol/inspector

This will open a web interface at http://localhost:5173 and allow you to interact with the MCP tools for testing.

For testing I create a symbolic link to the IDA plugin and then POST a JSON-RPC request directly to http://localhost:13337/mcp. After enabling symbolic links you can run the following command:

sh
uv run ida-pro-mcp --install

Generate the changelog of direct commits to main:

sh
git log --first-parent --no-merges 1.2.0..main "--pretty=- %s"

2. Official Technical Reference & Guides (mrexodia/docs)

File: README.md

Gitea: Docs



Hosting

This page is hosted on our infrastructure within Docker containers, it gets
automatically updated on every push to the master branch.

If you want to host this page on your own you can take our docker image
gitea/docs.

Install

This pages uses the Hugo static site generator.
If you are planning to contribute you'll want to download and install Hugo on
your local machine.

The installation of Hugo is out of the scope of this document, so please take
the official install instructions to
get Hugo up and running.

Development

To generate the website and serve it on localhost:1313
just execute this command and stop it with Ctrl+C:

text
make server

When you are done with your changes just create a pull request, after merging
the pull request the website will be updated automatically.

Contributing

Fork -> Patch -> Push -> Pull Request

Authors

License

This project is under the Apache-2.0 License. See the LICENSE file
for the full license text.

text
Copyright (c) 2016 The Gitea Authors <https://gitea.io>

File: content/page/index.en-us.md

date: "2016-11-08T16:00:00+02:00" title: "Documentation" slug: "documentation" weight: 10 toc: true draft: false

What is Gitea?

Gitea is a painless self-hosted Git service. It is similar to GitHub, Bitbucket or Gitlab. The initial development have been done on Gogs but we have forked it and named it Gitea. If you want to read more about the reasons why we have done that please read this blog post.

Purpose

The goal of this project is to make the easiest, fastest, and most painless way of setting up a self-hosted Git service. With Go, this can be done with an independent binary distribution across ALL platforms that Go supports, including Linux, macOS and Windows, even on architectures like ARM or PowerPC.

Features

  • User Dashboard
    • Context switcher (organization or current user)
    • Activity timeline
      • Commits
      • Issues
      • Pull requests
      • Repository creation
    • Searchable repository list
    • List of your organizations
    • A list of mirror repositories
  • Issues dashboard
    • Context switcher (organization or current user)
    • Filter by
      • Open
      • Closed
      • Your repositories
      • Assigned issues
      • Your issues
      • Repository
    • Sort by
      • Oldest
      • Last updated
      • Number of comments
  • Pull request dashboard
    • Same as issue dashboard
  • Repository types
    • Mirror
    • Normal
    • Migrated
  • Notifications (email and web)
    • Read
    • Unread
    • Pin
  • Explore page
    • Users
    • Repos
    • Organizations
    • Search
  • Custom templates
  • Override public files (logo, css, etc)
  • CSRF and XSS protection
  • HTTPS support
  • Set allowed upload sizes and types
  • Logging
  • Configuration
    • Databases
      • MySQL
      • PostgreSQL
      • SQLite3
      • MSSQL
      • TiDB (experimental)
    • Configuration file
    • Admin panel
      • Statistics
      • Actions
        • Delete inactive accounts
        • Delete cached repository archives
        • Delete repositories records which are missing their files
        • Run garbage collection on repositories
        • Rewrite SSH keys
        • Resync hooks
        • Recreate repositories which are missing
      • Server status
        • Uptime
        • Memory
        • Current # of goroutines
        • And more
      • User management
        • Search
        • Sort
        • Last login
        • Authentication source
        • Maximum repositories
        • Disable account
        • Admin permissions
        • Permission to create git hooks
        • Permission to create organizations
        • Permission to import repositories
      • Organization management
        • People
        • Teams
        • Avatar
        • Hooks
      • Repository management
        • See all repository information and manage repositories
      • Authentication sources
        • OAuth
        • PAM
        • LDAP
        • SMTP
      • Configuration viewer
        • Everything in config file
      • System notices
        • When somthing unexpected happens
      • Monitoring
        • Current processes
        • Cron jobs
          • Update mirrors
          • Repository health check
          • Check repository statstics
          • Clean up old archives
    • Environment variables
    • Command line options
  • Multi-language support (21 languages)
  • Mail service
    • Notifications
    • Registration confirmation
    • Password reset
  • Reverse proxy support
    • Includes subpaths
  • Users
    • Profile
      • Name
      • Username
      • Email
      • Website
      • Join date
      • Followers and following
      • Organizations
      • Repositories
      • Activity
      • Starred repositories
    • Settings
      • Same as profile and more below
      • Keep email private
      • Avatar
        • Gravatar
        • Libravatar
        • Custom
      • Password
      • Mutiple email addresses
      • SSH Keys
      • Connected applications
      • Two factor authentication
      • Linked OAuth2 sources
      • Delete account
  • Repositories
    • Clone with SSH/HTTP/HTTPS
    • Git LFS
    • Watch, Star, Fork
    • View watchers, stars, and forks
    • Code
      • Branch browser
      • Web based file upload and creation
      • Clone urls
      • Download
        • ZIP
        • TAR.GZ
      • Web based editor
        • Markdown editor
        • Plain text editor
          • Syntax highlighting
        • Diff preview
        • Preview
        • Choose where to commit to
      • View file history
      • Delete file
      • View raw
    • Issues
      • Issue templates
      • Milestones
      • Labels
      • Assign issues
      • Filter
        • Open
        • Closed
        • Assigned person
        • Created by you
        • Mentioning you
      • Sort
        • Oldest
        • Last updated
        • Number of comments
      • Search
      • Comments
      • Attachments
    • Pull requests
      • Same features as issues
    • Commits
      • Commit graph
      • Commits by branch
      • Search
      • Search in all branches
      • View diff
      • View SHA
      • View author
      • Browse files in commit
    • Releases
      • Attachments
      • Title
      • Content
      • Delete
      • Mark as pre-release
      • Choose branch
    • Wiki
      • Import
      • Markdown editor
    • Settings
      • Options
        • Name
        • Description
        • Private/Public
        • Website
        • Wiki
          • Enabled/disabled
          • Internal/external
        • Issues
          • Enabled/disabled
          • Internal/external
          • External supports url rewriting for better integration
        • Enable/disable pull requests
        • Transfer repository
        • Delete wiki
        • Delete repository
      • Collaboration
        • Read/write/admin
      • Branches
        • Default branch
        • Branch protection
      • Webhooks
      • Git hooks
      • Deploy keys

System Requirements

  • A cheap Raspberry Pi is powerful enough for basic functionality.
  • 2 CPU cores and 1GB RAM would be the baseline for teamwork.
  • Gitea is supposed to be run with a dedicated non-root user account on UNIX systems, no other mode of operation is supported. (NOTE: in case you run it with your own user account and the built-in SSH server disabled, Gitea modifies the ~/.ssh/authorized_keys file so you will not be able to interactively log in.)

Browser Support

  • Please see Semantic UI for specific versions of supported browsers.
  • The official support minimal size is 1024*768, UI may still looks right in smaller size but no promises and fixes.

Components

Software and Service Support

File: content/doc/advanced/config-cheat-sheet.en-us.md

date: "2016-12-26T16:00:00+02:00"
title: "Config Cheat Sheet"
slug: "config-cheat-sheet"
weight: 20
toc: false
draft: false
menu:
sidebar:
parent: "advanced"
name: "Config Cheat Sheet"
weight: 20
identifier: "config-cheat-sheet"

Configuration Cheat Sheet

This is a cheat sheet for the Gitea configuration file. It is helpful for more fully understanding how it powers Gitea.

Before getting started, make sure you know that any change to the configuration should be made in custom/conf/app.ini or any corresponding location.

All default settings can be found in app.ini (replace master in URL with name of tag for released versions). If you see anything which looks like %(X)s, it is a feature powered by ini for reading values recursively.

Any configuration option that is marked by :exclamation: means that you should keep the default value unless you fully understand what you are doing.

Values containing # or ; must be quoted using ` or """.

Note that you have to restart Gitea for changes to take effect.

Overall (`DEFAULT`)

  • APP_NAME: Application name, change to whatever you want.
  • RUN_USER: The user to run Gitea as, we recommend it be git; however, change this to whatever your username is if you run Gitea on your personal computer. Gitea may crash if this value is not set properly.
  • RUN_MODE: For performance and other purposes, change this to prod when deployed to a production environment. The installation process will set this to prod automatically.

Repository (`repository`)

  • ROOT: Root path for storing all users' repository data. It must be an absolute path. The default is ~//gitea-repositories.
  • SCRIPT_TYPE: The script type your server supports, usually this is bash, but some customers report that they only have sh.
  • ANSI_CHARSET: The default charset for an unrecognized charset.
  • FORCE_PRIVATE: Force every new repository to be private.
  • MAX_CREATION_LIMIT: Global maximum creation limit of repositories per user, -1 means no limit.
  • PULL_REQUEST_QUEUE_LENGTH:exclamation:: Length of pull request patch test queue, make it as large as possible.

UI (`ui`)

  • EXPLORE_PAGING_NUM: Number of repositories that are shown in one explore page.
  • ISSUE_PAGING_NUM: Number of issues that are shown in one page (for all pages that list issues).
  • FEED_MAX_COMMIT_NUM: Number of maximum commits shown in one activity feed.

UI - Admin (`ui.admin`)

  • USER_PAGING_NUM: Number of users that are shown in one page.
  • REPO_PAGING_NUM: Number of repos that are shown in one page.
  • NOTICE_PAGING_NUM: Number of notices that are shown in one page.
  • ORG_PAGING_NUM: Number of organizations that are shown in one page.

Markdown (`markdown`)

  • ENABLE_HARD_LINE_BREAK: Whether or not to enable hard the line break extension.

Server (`server`)

  • PROTOCOL: Either http, https, fcgi, or unix.
  • DOMAIN: Domain name of your server.
  • ROOT_URL: Full public URL of Gitea server.
  • HTTP_ADDR: HTTP listen address. If PROTOCOL is set to fcgi, Gitea will listen for FastCGI requests on TCP socket defined by HTTP_ADDR and HTTP_PORT configuration settings. If PROTOCOL is set to unix, this should be the name of the Unix socket file to use.
  • HTTP_PORT: HTTP listen port. If PROTOCOL is set to fcgi, Gitea will listen for FastCGI requests on TCP socket defined by HTTP_ADDR and HTTP_PORT configuration settings.
  • UNIX_SOCKET_PERMISSION: Permisson mode for Unix socket, default is 666.
  • DISABLE_SSH: Disables SSH feature when it's not available.
  • START_SSH_SERVER: Starts built-in SSH server when enabled.
  • SSH_DOMAIN: Domain name of your ssh server.
  • SSH_PORT: SSH port displayed in clone URL, in case yours is not 22.
  • SSH_LISTEN_PORT: Port for the built-in SSH server. Defaults to SSH_PORT.
  • OFFLINE_MODE: Disables use of CDN for static files and Gravatar for profile pictures.
  • DISABLE_ROUTER_LOG: Mutes printing of the router log.
  • CERT_FILE: Cert file path used for HTTPS.
  • KEY_FILE: Key file path used for HTTPS.
  • STATIC_ROOT_PATH: Upper level of template and static files path, default is the path where Gitea is located.
  • ENABLE_GZIP: Enables application-level GZIP support.
  • LANDING_PAGE: Non-logged-in users' landing page, either home or explore.
  • LFS_START_SERVER: Enables git-lfs support. true or false, default is false.
  • LFS_CONTENT_PATH: Where your lfs files put on, default is data/lfs.
  • LFS_JWT_SECRET: LFS authentication secret, changed this to yourself.

Database (`database`)

  • DB_TYPE: The database type you choose, either mysql, postgres, mssql or sqlite3.
  • HOST: Database host address and port.
  • NAME: Database name.
  • USER: Database username.
  • PASSWD: Database user password.
  • SSL_MODE: For PostgreSQL only.
  • PATH: For SQLite3 only, the database file path.

Security (`security`)

  • INSTALL_LOCK: Indicates whether to allow the open install page (setting admin account is involved, so it's a very important value).
  • SECRET_KEY: Global secret key for your server security, you'd better change it (will generate a random string every time you install).
  • LOGIN_REMEMBER_DAYS: Cookie lifetime, in days.
  • COOKIE_USERNAME: Name of the cookie that saves username.
  • COOKIE_REMEMBER_NAME: Name of cookie that saves auto-login information.
  • REVERSE_PROXY_AUTHENTICATION_USER: Header name for reverse proxy authentication username.
  • DISABLE_GIT_HOOKS: Prevent all users (including admin) from creating custom git hooks (defaults to false)

OpenID (`openid`)

  • ENABLE_OPENID_SIGNIN: Whether to allow signin in via OpenID (defaults to false).
  • ENABLE_OPENID_SIGNUP: Whether to allow registering via OpenID (defaults to !DISABLE_REGISTRATION).
  • WHITELISTED_URIS: Space separated list of POSIX regexp patterns. If non empty OpenID URIs should match any of these to be granted access.
  • BLACKLISTED_URIS: Space separated list of POSIX regexp pattenrs. OpenID URI matching any of these is refused access.

Service (`service`)

  • ACTIVE_CODE_LIVE_MINUTES: The minutes of active code life time.
  • RESET_PASSWD_CODE_LIVE_MINUTES: The minutes of reset password code life time.
  • REGISTER_EMAIL_CONFIRM: Enable this to ask for mail confirmation of registration, requires Mailer to be enabled.
  • DISABLE_REGISTRATION: Disable registration, after which only admin can create accounts for users.
  • SHOW_REGISTRATION_BUTTON: Indicate whether to show registration button or not.
  • REQUIRE_SIGNIN_VIEW: Enable this to force users to log in to view any page.
  • ENABLE_CACHE_AVATAR: Enable this to cache avatar from Gravatar.
  • ENABLE_NOTIFY_MAIL: Enable this to send e-mail to watchers of repository when something happens like creating issues, requires Mailer to be enabled.
  • ENABLE_REVERSE_PROXY_AUTHENTICATION: Enable this to allow reverse proxy authentication, more detail: https://github.com/gogits/gogs/issues/165
  • ENABLE_REVERSE_PROXY_AUTO_REGISTRATION: Enable this to allow auto-registration for reverse authentication.
  • DISABLE_MINIMUM_KEY_SIZE_CHECK: Do not check minimum key size with corresponding type.
  • ENABLE_CAPTCHA: Enable this to use captcha validation for registration.

Webhook (`webhook`)

  • QUEUE_LENGTH:exclamation:: Hook task queue length.
  • DELIVER_TIMEOUT: Delivery timeout in seconds for shooting webhooks.
  • SKIP_TLS_VERIFY: Indicate whether to allow insecure certification or not.
  • PAGING_NUM: Number of webhook history that are shown in one page.

Mailer (`mailer`)

  • ENABLED: Enable this to use a mail service.
  • DISABLE_HELO: Disable HELO operation.
  • HELO_HOSTNAME: Custom hostname for HELO operation.
  • HOST: SMTP mail host address and port (example: smtp.gitea.io:587).
  • FROM: Mail from address, RFC 5322. This can be just an email address, or the "Name" \ format.
  • USER: Username of mailer (usually just your e-mail address).
  • PASSWD: Password of mailer.
  • SKIP_VERIFY: Do not verify the self-signed certificates.
  • USE_SENDMAIL: Use the operating system's sendmail command instead of SMTP. This is common on linux systems. Valid values are true to use sendmail and false to use SMTP (default). Note that enabling sendmail will ignore all other mailer settings except ENABLED, FROM and SENDMAIL_PATH.
  • SENDMAIL_PATH: The location of sendmail on the operating system. This can be an absolute path (eg: /usr/sbin/sendmail) or just the name of the command (eg: sendmail - default) if it can be found in the PATH environment variable.

Note: Actually, Gitea supports only SMTP with STARTTLS.

Cache (`cache`)

  • ADAPTER: Cache engine adapter, either memory, redis, or memcache. If you want to use redis or memcache, be sure to rebuild everything with build tags redis or memcache: go build -tags='redis'.
  • INTERVAL: for memory cache only, GC interval in seconds.
  • HOST: For redis and memcache, the host address and port number.
    • Redis: network=tcp,addr=127.0.0.1:6379,password=macaron,db=0,pool_size=100,idle_timeout=180
    • Memache: 127.0.0.1:9090;127.0.0.1:9091

Session (`session`)

  • PROVIDER: Session engine provider, either memory, file, redis, or mysql.
  • PROVIDER_CONFIG: For file, it's the root path; for others, it's the host address and port number.
  • COOKIE_SECURE: Enable this to force using HTTPS for all session access.
  • COOKIE_NAME: The name of the cookie used for the session ID, defaults to i_like_gitea.
  • GC_INTERVAL_TIME: GC interval in seconds.

Picture (`picture`)

  • GRAVATAR_SOURCE: Can be gravatar, duoshuo or anything like http://cn.gravatar.com/avatar/.
  • DISABLE_GRAVATAR: Enable this to use local avatars only.
  • ENABLE_FEDERATED_AVATAR: Enable support for federated avatars (see http://www.libravatar.org)
  • AVATAR_UPLOAD_PATH: Path to store local and cached files.

Attachment (`attachment`)

  • ENABLED: Enable this to allow users upload attachments.
  • PATH: Path to store attachments.
  • ALLOWED_TYPES: Allowed MIME types, e.g. image/jpeg|image/png, use */* for all types.
  • MAX_SIZE: Maximum size in MB, e.g. 4
  • MAX_FILES: Maximum number of attachments can be uploaded at once, e.g. 5.

Log (`log`)

  • ROOT_PATH: Root path for log files.
  • MODE: Logging mode, default is console. For multiple modes, use comma to separate it.
  • LEVEL: General log level, default is Trace.

Cron (`cron`)

  • ENABLED: Enable this to run cron tasks periodically.
  • RUN_AT_START: Enable this to run cron tasks at start time.

Cron - Update Mirrors (`cron.update_mirrors`)

  • SCHEDULE: Cron syntax for scheduling update mirrors, e.g. @every 1h.

Cron - Repository Health Check (`cron.repo_health_check`)

  • SCHEDULE: Cron syntax for scheduling repository health check, e.g. @every 24h.
  • TIMEOUT: Time duration syntax for health check execution timeout, e.g. 60s.
  • ARGS: Arguments for command git fsck, e.g. --unreachable --tags.

Cron - Repository Statistics Check (`cron.check_repo_stats`)

  • RUN_AT_START: Enable this to run repository statistics check at start time.
  • SCHEDULE: Cron syntax for scheduling repository statistics check, e.g. @every 24h.

Git (`git`)

  • MAX_GIT_DIFF_LINES: Max number of lines allowed of a single file in diff view.
  • MAX_GIT_DIFF_LINE_CHARACTERS: Max number of characters of a line allowed in diff view.
  • MAX_GIT_DIFF_FILES: Max number of files shown in diff view.
  • GC_ARGS: Arguments for command git gc, e.g. --aggressive --auto.

Other (`other`)

  • SHOW_FOOTER_BRANDING: Enable this to show Gitea branding in the footer.
  • SHOW_FOOTER_VERSION: Enable this to show Gitea version information in the footer.
  • SHOW_FOOTER_TEMPLATE_LOAD_TIME: Enable this to show time of template execution in the footer.

File: content/doc/advanced/customizing-gitea.en-us.md

date: "2017-04-15T14:56:00+02:00"
title: "Customizing Gitea"
slug: "customizing-gitea"
weight: 9
toc: false
draft: false
menu:
sidebar:
parent: "advanced"
name: "Customizing Gitea"
weight: 9
identifier: "customizing-gitea"

Customizing Gitea

The main way to customize Gitea is by using the custom folder. This is the central place to override and configure features.

If you install Gitea from binary, after the installation process ends, you can find the custom folder next to the binary.
Gitea will create the folder for you and prepopulate it with a conf folder inside, where Gitea stores all the configuration settings provided through the installation steps (have a look here for a complete list).

If you can't find the custom folder next to the binary, please check the GITEA_CUSTOM environment variable, that can be used to override the default path to something else. GITEA_CUSTOM might be set for example in your launch script file. Please have a look here for a complete list of environment variables.

Note that you have to restart Gitea for it to notice the changes.

Customizing /robots.txt

To make Gitea serve your own /robots.txt (by default, an empty 404 status is served), simply create a file called robots.txt in the custom folder with the expected contents.

Serving custom public files

To make Gitea serve custom public files (like pages and images), use the folder custom/public/ as the webroot. Symbolic links will be followed.

For example, a file image.png stored in custom/public, can be accessed with the url http://your-gitea-url/image.png.

Changing the default avatar

Place the png image at the following path: custom/public/img/avatar_default.png

Customizing Gitea pages

The custom/templates folder allows you to change every single page of Gitea.

You need to be aware of the template you want to change. All templates can be found in the templates folder of the Gitea sources.

When you find the correct .tmpl file, you need to copy it in the custom/templates folder of your installation, respecting any subfolder you found in the source template.

You can now customize the template you copied in custom/templates, being carefully to not break the Gitea syntax.
Any statement contained inside {{ and }} are Gitea templete's syntax and shouldn't be touch, unless you know what are you doing.

Customizing gitignores, labels, licenses, locales, and readmes.

Place your own files in corresponding sub-folder under custom/options.

File: content/doc/advanced/hacking-on-gitea.en-us.md

date: "2016-12-01T16:00:00+02:00"
title: "Hacking on Gitea"
slug: "hacking-on-gitea"
weight: 10
toc: false
draft: false
menu:
sidebar:
parent: "advanced"
name: "Hacking on Gitea"
weight: 10
identifier: "hacking-on-gitea"

Hacking on Gitea

We won't cover the basics of a Golang setup within this guide. If you don't know how to get the environment up and running you should follow the official install instructions.

If you want to contribute to Gitea you should fork the project and work on the master branch. There is a catch though, some internal packages are referenced by their GitHub URL. So you have to trick the Go tool to think that you work on a clone of the official repository. Start by downloading the source code as you normally would:

text
go get -d code.gitea.io/gitea

Now it's time to fork the Gitea repository on GitHub, after that you should have to switch to the source directory on the command line:

text
cd $GOPATH/src/code.gitea.io/gitea

To be able to create pull requests you should add your forked repository as a remote to the Gitea sources, otherwise you can not apply the changes to our repository because of lacking write permissions:

text
git remote rename origin upstream
git remote add origin [email protected]:/gitea.git
git fetch --all --prune

You've got a working development environment for Gitea now. Take a look at the Makefile to get an overview about the available tasks. The most common tasks should be make test which will start our test environment and make build which will build a gitea binary into your working directory. Writing test cases is not mandatory to contribute, but we will be happy if you do.

That’s it! You are ready to hack on Gitea. Test your changes, push them to your repository and open a pull request.

File: content/doc/advanced/make.en-us.md

date: "2017-01-14T11:00:00-02:00"
title: "Make"
slug: "make"
weight: 10
toc: true
draft: false
menu:
sidebar:
parent: "advanced"
name: "Make"
weight: 30
identifier: "make"

Make

Gitea makes heavy use of Make to automate tasks and have a faster development. This guide cover how to install Make.

On Linux

You can install with your package manager.

On Ubuntu/Debian:

bash
sudo apt-get install build-essential

On Fedora/RHEL/CentOS:

bash
sudo yum install make

On Windows

If you are using Windows, you can download and use one of these distributions of Make:

File: content/doc/advanced/specific-variables.en-us.md

date: "2017-04-08T11:34:00+02:00"
title: "Specific variables"
slug: "specific-variables"
weight: 20
toc: false
draft: false
menu:
sidebar:
parent: "advanced"
name: "Specific variables"
weight: 20
identifier: "specific-variables"

Specific variables

This is an inventory of Gitea environment variables. They change Gitea behaviour.

Initialize them before Gitea command to be effective, for example:

text
GITEA_CUSTOM=/home/gitea/custom ./gitea web

From Go language

As Gitea is written in Go, it uses some Go variables as:

  • GOOS
  • GOARCH
  • GOPATH

For GOPATH, check official documentation about GOPATH environment variable.

For others, check official documentation about variables used when it runs the generator.

Gitea files

  • GITEA_WORK_DIR: Gitea absolute path of work directory.
  • GITEA_CUSTOM: Gitea uses GITEA_WORK_DIR/custom folder by default. Use this variable to change custom directory.
  • GOGS_WORK_DIR: Deprecated, use GITEA_WORK_DIR
  • GOGS_CUSTOM: Deprecated, use GITEA_CUSTOM

Operating system specifics

  • USER: system user that launch Gitea. Useful for repository URL address on Gitea interface
  • USERNAME: if no USER found, Gitea will try USERNAME
  • HOME: User home directory path (except if you're running on Windows, check the following USERPROFILE variable)

Only on Windows

  • USERPROFILE: User home directory path. If empty, uses HOMEDRIVE + HOMEPATH
  • HOMEDRIVE: Main drive path you will use to get home directory
  • HOMEPATH: Home relative path in the given home drive path

Macaron (framework used by Gitea)

  • HOST: Host Macaron will listen on
  • PORT: Port Macaron will listen on
  • MACARON_ENV: global variable to provide special functionality for development environments vs production environments. If MACARON_ENV is set to "" or "development" then templates will be recompiled on every request. For more performance, set the MACARON_ENV environment variable to "production".

Miscellaneous

  • SKIP_MINWINSVC: Do not run as a service on Windows if set to 1
  • ZOOKEEPER_PATH: Zookeeper jar file path

File: content/doc/features/authentication.en-us.md

date: "2016-12-01T16:00:00+02:00"
title: "Authentication"
slug: "authentication"
weight: 10
toc: true
draft: false
menu:
sidebar:
parent: "features"
name: "Authentication"
weight: 10
identifier: "authentication"

Authentication

TBD

File: content/doc/features/localization.en-us.md

date: "2016-12-01T16:00:00+02:00"
title: "Localization"
slug: "localization"
weight: 10
toc: true
draft: false
menu:
sidebar:
parent: "features"
name: "Localization"
weight: 20
identifier: "localization"

Localization

TBD

File: content/doc/features/webhooks.en-us.md

date: "2016-12-01T16:00:00+02:00"
title: "Webhooks"
slug: "webhooks"
weight: 10
toc: true
draft: false
menu:
sidebar:
parent: "features"
name: "Webhooks"
weight: 30
identifier: "webhooks"

Webhooks

Gitea supports web hooks for repository events, you can find it in settings page(/:username/:reponame/settings/hooks). All event pushes are POST requests, and we currently support two formats: Gitea and Slack.

Event information

Following shows an example of event information that will be sent by Gitea to Payload URL:

text
X-Github-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
X-Github-Event: push
X-Gogs-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
X-Gogs-Event: push
X-Gitea-Delivery: f6266f16-1bf3-46a5-9ea4-602e06ead473
X-Gitea-Event: push
text
/* Detailed source-code truncated for AI context efficiency. */

--- METRICS ---

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

#ai Browse ai catalog → #aiagent Browse aiagent catalog → #binary-analysis Browse binary-analysis catalog → #ida-plugin Browse ida-plugin catalog → #ida-pro Browse ida-pro catalog → #mcp Browse mcp catalog → ⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →