How to Add AI to Jira Data Center in 5 Minutes

If your organization runs Atlassian Jira on Data Center, you've probably noticed that most AI tools for Atlassian are cloud-only. Atlassian's own Rovo requires a Cloud organization and sends your Data Center data to their cloud for processing. For teams that chose Data Center specifically for data control, security, or compliance reasons, that defeats the purpose. The good news is that you can add a full AI assistant to your Jira Data Center deployment in about five minutes using Foxbridge — a self-hosted Docker application that runs on your own infrastructure, connects to your DC instance, and keeps all data on your network.

What do you need before starting?

You need four things to get started: Docker installed on a server that can reach your Jira Data Center instance (this can be the same server or any machine on the same network), an AI provider API key from Anthropic, OpenAI, or Azure OpenAI (or Ollama installed locally for fully air-gapped deployments), a Foxbridge license key which you can get as a free 14-day trial at foxbridge.dev/pricing, and a Personal Access Token from your Jira Data Center instance for authentication. If your Data Center deployment is behind a firewall, the Docker container just needs network access to your Jira, Confluence, and Bitbucket URLs — no inbound ports, no public internet, no application tunnels.

Step 1: Create your configuration file

Create a directory for Foxbridge and add a foxbridge.yaml configuration file. This file tells Foxbridge where your Data Center instance is, how to authenticate, and which AI provider to use. Replace the placeholder values with your actual URLs, license key, and API key:

license_key: "FK-XXXXXXXX-XXXXXXXX-XXXXXXXX"

atlassian:
  platform: "datacenter"
  base_url: "https://jira.yourcompany.com"
  auth_method: "pat"
  jira_url: "https://jira.yourcompany.com/jira"
  confluence_url: "https://confluence.yourcompany.com/confluence"

ai:
  provider: "anthropic"
  api_key: "sk-ant-..."

features:
  jira:
    read: true
    write: false
  confluence:
    read: true
    write: false
  bitbucket:
    read: true
    write: false

If your Jira, Confluence, and Bitbucket are on different servers, specify each URL individually with the jira_url, confluence_url, and bitbucket_url fields. If they share the same base URL, you only need base_url. For authentication, use auth_method: "pat" for Personal Access Tokens (recommended for security) or auth_method: "basic" for username and password. See the full configuration reference for all available options.

Step 2: Create Docker Compose file and start Foxbridge

In the same directory, create a docker-compose.yml file:

services:
  foxbridge:
    image: ghcr.io/foxbridge-ai/foxbridge:latest
    ports:
      - "3000:3000"
      - "3001:3001"
    volumes:
      - ./foxbridge.yaml:/app/foxbridge.yaml:ro
      - foxbridge-data:/var/lib/foxbridge
    restart: unless-stopped

volumes:
  foxbridge-data:

Then start Foxbridge with docker compose up -d. Docker will pull the image (about 200MB), start the container, validate your license key, and begin listening on port 3000 for the web chat interface and port 3001 for MCP IDE integration. You should see the startup logs within a few seconds by running docker compose logs -f.

Step 3: Log in and start using AI with your Data Center

Open http://your-server:3000 in your browser. You'll see the Foxbridge login page. Enter your Data Center username and Personal Access Token (or username and password if using basic auth). Once logged in, you can immediately start asking questions in natural language: "Show me open bugs in the PROJ project", "Summarize the comments on PROJ-123", "What pages in Confluence mention the release process?", or "List open pull requests in the backend repo". Foxbridge translates your questions into JQL queries, Confluence searches, and Bitbucket API calls — all running against your Data Center instance, all staying on your network.

What about air-gapped environments?

If your Data Center environment has no external internet access at all, you can use Ollama as the AI provider instead of Anthropic or OpenAI. Ollama runs large language models entirely on your local hardware — install it on the same server as Foxbridge, pull a model like Llama 3.1 or Mistral, and set provider: "ollama" in your configuration. No API key needed, no external network connection, complete air-gap compliance. The AI quality is good for most use cases, though cloud-hosted models like Claude and GPT-4o are more capable for complex reasoning tasks.

What can Foxbridge do with your Jira Data Center?

Foxbridge provides over 40 AI-powered tools across Jira, Confluence, and Bitbucket. For Jira specifically, you can search issues with natural language instead of writing JQL, read and summarize issue details and comment threads, create and update issues through conversation, manage sprint boards and backlogs, transition issue workflows, add comments and attachments, link related issues, and log work. If you enable write mode in the configuration, Foxbridge can create tickets, add comments, and transition workflows — always showing a preview and asking for confirmation before making changes. The AI understands context across your conversation, so you can ask follow-up questions like "now show me just the critical ones" or "create a ticket for that bug we just discussed".

What are real-world use cases for AI on Jira Data Center?

The quickest way to understand what Foxbridge can do is to see the kinds of questions teams actually ask it. Here are six scenarios we see regularly across engineering, product, and leadership teams.

Sprint planning and backlog grooming. At the start of a sprint, teams waste time manually reviewing what carried over from the last cycle. Instead of clicking through boards and filters, you can ask Foxbridge: "Show me all unfinished stories from last sprint and create new tickets for the carryover items." Foxbridge will query your Jira Data Center for incomplete issues in the previous sprint, list them with their current status and assignee, and — if you have write mode enabled — offer to create new tickets in the current sprint for each carryover item. This turns a 30-minute grooming session into a 2-minute conversation.

Bug triage and pattern detection. When your support queue fills up, the first step is understanding what's actually happening. Ask Foxbridge: "Find all critical bugs reported this week and summarize the common themes." It will run the JQL query against your Data Center instance, pull back the matching issues, read through their descriptions and comments, and give you a grouped summary — for example, "12 critical bugs this week: 5 related to the payment gateway timeout, 4 related to the new user registration flow, and 3 isolated issues." That kind of pattern detection is tedious to do manually but takes seconds with AI.

Stakeholder updates and status reports. Writing a monthly update for leadership usually means spending an hour digging through resolved tickets to remember what your team actually shipped. Foxbridge can do that research for you: "Generate a summary of what the Platform team shipped this month based on resolved Jira tickets." It will search for issues resolved in the date range, filter by project or team, and produce a narrative summary grouped by theme — infrastructure improvements, feature work, bug fixes, and so on. You get a first draft in seconds that you can polish and send.

Confluence documentation from Jira data. If your team tracks deployments or processes through Jira tickets, Foxbridge can turn that operational data into documentation. Try: "Draft a Confluence page documenting the release process based on our DEPLOY tickets." Foxbridge will search your DEPLOY project, read through the ticket descriptions and comments to understand the workflow, and generate a structured Confluence page with the steps, owners, and common issues. If you have Confluence write mode enabled, it can publish the draft directly to your space for review.

Code review context from linked tickets. Developers reviewing pull requests often need to understand the requirements behind a change. Instead of switching to Jira and searching manually, ask Foxbridge: "Show me the Jira ticket linked to PR #142 and summarize the requirements." Foxbridge will look up the pull request in Bitbucket, find the linked Jira issue, and give you a concise summary of the acceptance criteria, any relevant comments from product or design, and the current status. This keeps your code review focused on whether the implementation matches the intent.

Onboarding new team members. When someone joins a team, they need to build context quickly — what does this project actually do, what kind of work happens here, and who should they ask about what? Foxbridge can answer: "What are the most common ticket types in the INFRA project and who typically works on them?" It will analyze recent issues in the project, break down the distribution of ticket types (incidents, feature requests, maintenance tasks), and identify the most active contributors for each category. New team members get an instant map of the project landscape without needing to bother their teammates for context.

What are the system requirements?

Foxbridge is designed to run on minimal infrastructure. The Docker image is about 200MB, and the container itself is lightweight enough to share a server with your existing services.

Docker. Any modern version of Docker will work — Docker Engine 20.10+ or Docker Desktop. If you use Podman or another OCI-compatible runtime, that works too. You need Docker Compose if you want to use the docker-compose.yml approach shown in this guide, but you can also run the container directly with docker run.

CPU and memory. The minimum requirement is 1 CPU core and 512MB of RAM. For production use with multiple concurrent users, we recommend 2 CPU cores and 1GB of RAM. Foxbridge itself is not doing the heavy AI computation — that happens at your AI provider (Anthropic, OpenAI, or Azure OpenAI). The container handles request routing, authentication, tool orchestration, and streaming responses, which is not resource-intensive.

Disk space. The Docker image requires approximately 200MB of disk space. The container is stateless by design — it does not maintain a database or store conversation history on disk. The only persistent data is a small license validation cache stored in the mounted volume, which ensures the container can start up quickly without re-validating the license on every restart. If you delete the volume, the container simply re-validates on next startup.

Network access. The container needs to reach your Atlassian Data Center instance over the network — specifically the URLs you configure for Jira, Confluence, and Bitbucket. This is outbound-only traffic from the container to your DC servers. No inbound ports need to be opened on your DC instance beyond what it already exposes. The container does not require public internet access for core functionality. The only external call is license validation at startup, which can be skipped in air-gapped environments with an offline license key.

AI provider. You need an API key from Anthropic, OpenAI, or Azure OpenAI — or you can run Ollama locally for fully air-gapped deployments. If you use Ollama, you will need additional resources for the local model (typically 8GB+ RAM depending on the model size), but no external network access at all.

What about security and compliance?

If your organization chose Data Center over Cloud, security and data control are probably non-negotiable. Foxbridge is built for exactly this environment.

All data stays on your network. Foxbridge runs on your infrastructure and connects directly to your Atlassian Data Center instance. Your Jira issues, Confluence pages, and Bitbucket repositories are queried in real-time over your internal network. Nothing is cached, indexed, or stored by Foxbridge beyond the current conversation session. When the conversation ends, the data is gone.

No telemetry or usage data. Foxbridge does not send telemetry, usage analytics, or any operational data back to Foxbridge (Plip Software). The only network call to our servers is license key validation at container startup, which sends the license key and receives a validation response. No information about your Atlassian instance, your users, your queries, or your data is included in that call.

PII scrubbing for regulated industries. If you work in healthcare, finance, or another regulated industry and need to use a cloud-hosted AI provider, Foxbridge includes a PII scrubbing layer that can strip personally identifiable information from the data before it is sent to the AI provider. This means names, email addresses, and other sensitive fields can be redacted from the AI context while still giving you useful results. For maximum data control, pair PII scrubbing with Ollama to keep everything — including AI inference — entirely on your network.

Authentication and credential handling. Foxbridge authenticates to your Data Center instance using either a Personal Access Token (PAT) or basic authentication (username and password). Critically, Foxbridge does not store these credentials. They are provided by each user at login and used for the duration of that session only. Every Jira query, Confluence search, and Bitbucket API call is made using the logged-in user's credentials, which means all actions respect your existing Data Center permission model. If a user does not have access to a project in Jira, they cannot access it through Foxbridge either.

Audit logging. On Business and Enterprise tiers, Foxbridge provides audit logging that records which users made which queries and what tools were invoked. This gives your security team visibility into how the AI assistant is being used without exposing the content of conversations. Audit logs can be exported to your existing SIEM or log management system for centralized monitoring.

Read the full setup guide →