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.

Creating the Personal Access Token

PATs are the recommended auth method because you never have to put a password anywhere. Atlassian added them to Jira Data Center in 8.14 and Confluence Data Center in 7.9, so any reasonably current DC deployment has them. To create one: log in to Jira, click your profile icon (top right) → Profile → Personal Access Tokens → Create token. Name it something obvious like "Foxbridge", set an expiry date, and copy the token immediately — Jira won't show it to you again.

One thing that surprises people coming from Atlassian Cloud: Data Center PATs have no permission scopes to configure. The token simply inherits the full permissions of the user who created it. That sounds alarming until you realize how Foxbridge uses it — there is no shared service-account token. Each user enters their own PAT when they log in to Foxbridge, and every Jira query, Confluence search, and Bitbucket call runs as that user. Your existing DC permission scheme is the access control. The practical implication: set a sensible expiry (90 days is a common policy) and treat the token like a password, because it is one.

Network requirements

Plan for four traffic paths before you start — a large share of the troubleshooting sessions I end up in are really firewall questions in disguise:

Container → Atlassian DC: outbound HTTPS from the Foxbridge container to your Jira, Confluence, and Bitbucket URLs. No inbound ports need to open on the DC side beyond what it already serves, and no application tunnels are involved.
Container → AI provider: outbound HTTPS to your provider's API (e.g. Anthropic or OpenAI), or to Azure if you use Azure OpenAI. If you use Ollama, this path stays entirely on your network. If your servers route through an egress proxy, this is the path that needs an exception.
Container → foxbridge.dev: license validation at startup, revalidated every 6 hours. If the validation server is unreachable, a 72-hour grace period keeps you running, so a flaky proxy won't take the service down mid-week.
Users → container: your team's browsers need to reach port 3000 on the Foxbridge host, and IDE users need port 3001 for MCP.

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. Here is the full annotated configuration with every available option — most deployments only change three values (license key, base URL, API key) and leave the rest at defaults:

license_key: "FK-XXXXXXXX-XXXXXXXX-XXXXXXXX"   # from foxbridge.dev/pricing

atlassian:
  platform: "datacenter"
  base_url: "https://jira.yourcompany.com"  # your DC server URL
  auth_method: "pat"                # "pat" (recommended) or "basic"
  jira_url: ""                      # optional: override if Jira lives elsewhere
  confluence_url: ""                # optional: override for Confluence
  bitbucket_url: ""                 # optional: override for Bitbucket

ai:
  provider: "anthropic"             # "anthropic", "openai", "azure_openai", or "ollama"
  api_key: "sk-ant-..."             # not needed for Ollama
  model: ""                         # optional: override the default model
  base_url: ""                      # required for azure_openai and ollama

features:
  jira:
    read: true
    write: false                    # start read-only; flip to true when ready
  confluence:
    read: true
    write: false
  bitbucket:
    read: true
    write: false

scrub_pii: false                    # redact PII before it reaches the AI provider
log_level: "info"                   # "debug", "info", "warn", or "error"
port_chat: 3000                     # web chat UI port
port_mcp: 3001                      # MCP transport port

The atlassian block. Set platform: "datacenter" and point base_url at your server. If Jira, Confluence, and Bitbucket share one base URL, that single field is all you need. If they run on different servers — common in larger DC deployments — set jira_url, confluence_url, and bitbucket_url individually. For authentication, auth_method: "pat" is the recommended option; auth_method: "basic" (username and password) exists for instances where PATs are unavailable. Under the hood, Foxbridge talks to the standard REST API v2 endpoints on Data Center.

The ai block. Pick one of four providers: anthropic (best for tool use, and the only one with image analysis support), openai, azure_openai, or ollama. The model field is optional — with Anthropic it defaults to the latest Sonnet model. Two provider-specific gotchas worth knowing up front: for Azure OpenAI, base_url must be your Azure resource endpoint and model must be your deployment name, not the model name; for Ollama, base_url is required and no API key is needed.

The features block. This is your blast-radius control. Each product has independent read and write flags. My standing advice: run read-only for the first week. Read-only Foxbridge can still search, summarize, and answer questions — which is most of the value — and it gives your security team time to review audit needs before the AI can create or modify anything. When you enable write, Foxbridge still previews every change and asks for confirmation before executing it.

Global options. scrub_pii: true turns on PII redaction before data leaves for the AI provider (more on this below). log_level: "debug" is your friend during initial setup and too noisy after. port_chat and port_mcp let you move the listening ports if 3000 or 3001 collide with something else on the host. See the full configuration reference for the complete option list.

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.

How do you connect the MCP endpoint to Claude Code, VS Code, or Cursor?

The web chat is where most people start, but the part developers end up using daily is the MCP endpoint. Foxbridge exposes a Model Context Protocol server on port 3001, which means any MCP-compatible client — Claude Code, VS Code, Cursor — can use the same Jira, Confluence, and Bitbucket tools directly from the editor. In practice this looks like asking your coding assistant "what are the acceptance criteria on PROJ-456?" while you're implementing it, without ever opening a browser tab.

Claude Code. Add Foxbridge to your MCP settings file (project-level .mcp.json or your user-level config):

{
  "mcpServers": {
    "foxbridge": {
      "url": "http://your-server:3001/sse"
    }
  }
}

Or register it from the terminal in one line:

claude mcp add --transport sse foxbridge http://your-server:3001/sse

VS Code and Cursor. Install the MCP extension (VS Code) or open Cursor's MCP settings, then add the server URL http://your-server:3001/sse. Both editors will list the Foxbridge tools alongside their built-in capabilities once the connection is established.

Two practical notes. First, your-server is wherever the Foxbridge container runs — localhost if it's on your machine, otherwise the internal hostname, which means developer workstations need network access to port 3001 on that host. Second, the MCP endpoint exposes the same tool set as the web chat and respects the same features read/write flags from your foxbridge.yaml, so a read-only deployment stays read-only no matter which client connects.

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 with ollama pull llama3.1, and update the ai block of your configuration:

ai:
  provider: "ollama"
  base_url: "http://host.docker.internal:11434"
  model: "llama3.1"

No API key needed, no external network connection, complete air-gap compliance. The host.docker.internal hostname is what lets the Docker container reach Ollama running on the host machine — a detail that trips people up if they put localhost there instead, because inside the container, localhost is the container. 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 goes wrong, and how do you fix it?

Most setups work on the first docker compose up. When they don't, the failure almost always falls into one of five buckets. Start with docker compose logs -f — Foxbridge logs the specific error, and a healthy startup ends with Foxbridge listening on :3000 (chat) and :3001 (MCP).

"License validation failed"

First check the boring thing: that license_key in your YAML matches the key you received exactly, with no trailing whitespace from a sloppy paste. If the key is right, the container probably can't reach foxbridge.dev — test from the Docker host with curl https://foxbridge.dev/api/license/validate?key=YOUR_KEY. In proxied environments this is usually an egress rule that nobody opened. Remember the validation result is cached with a 72-hour grace period, so once you're past first startup, brief outages won't bite you.

"Atlassian authentication failed"

Three causes cover nearly every case. One: the PAT expired — DC tokens have expiry dates and people forget them; create a fresh token and log in again. Two, and this is the gotcha I see most often: base_url is missing the context path. If your Jira lives at https://jira.company.com/jira rather than at the root, the config needs that full path including /jira — without it, Foxbridge's API calls hit the wrong endpoints and auth fails in a confusing way. Three: if you're on auth_method: "basic", the username or password is simply wrong, or your DC instance is forcing CAPTCHA after failed attempts, which basic auth can't answer.

AI provider errors

If chat responses fail after login, the Atlassian side is fine and the AI side isn't. Check that your API key is valid and the account has credit or quota remaining. Azure OpenAI has its own classic mistake: model must be your deployment name from the Azure portal, not the underlying model name, and base_url must be your resource endpoint. For Ollama, confirm the daemon is actually running (ollama serve) and the model has been pulled, and that base_url uses host.docker.internal, not localhost.

Firewall and connectivity issues

If the logs show timeouts to your Jira URL, test the path the container actually uses: docker compose exec foxbridge curl -sk https://jira.yourcompany.com tells you whether the container can reach DC at all. Internal TLS certificates from a corporate CA are a frequent culprit in DC environments — if your Jira presents a cert the container doesn't trust, requests fail. And if users can't load the chat page itself, check that port 3000 is reachable from their network segment; the container is listening, but a host firewall or security group is often not forwarding.

Port conflicts

If startup fails because 3000 or 3001 is already taken on the host — port 3000 in particular is popular with dev servers — you don't have to evict the other service. Set port_chat and port_mcp in foxbridge.yaml, or just remap the host side in docker-compose.yml (e.g. "8080:3000"), and update the URLs your users and MCP clients point at.

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, government, or another regulated industry and need to use a cloud-hosted AI provider, set scrub_pii: true in your configuration. Foxbridge will detect and redact personally identifiable information — email addresses, phone numbers, and names based on common patterns — before the data is sent to the AI provider. The scrubbing happens in-memory inside Foxbridge, so the provider never sees the original PII. Enterprise-tier deployments can define custom PII rules and redaction policies on top of the built-in patterns. 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.

Frequently asked questions

Does any Jira data leave my network?

That depends entirely on which AI provider you choose. With Anthropic, OpenAI, or Azure OpenAI, the context needed to answer a question — issue summaries, comments, search results — is sent to that provider's API for inference, optionally with PII scrubbed first. With Ollama, nothing leaves your network at all. Either way, Foxbridge itself stores nothing persistently and sends no telemetry; the only call to our servers is license validation.

Isn't Rovo the official way to get AI on Data Center?

As of mid-2026, Atlassian's own FAQ is clear that Rovo's AI features require an Atlassian Cloud Standard, Premium, or Enterprise plan. For Data Center customers, Atlassian offers Rovo Data Center connectors, which synchronize your Jira and Confluence data into a cloud environment so the cloud-based AI can operate on it. If syncing DC data to Atlassian's cloud is acceptable for your organization, that path exists. If the whole point of your DC deployment is that the data doesn't leave, it isn't an option — which is the gap Foxbridge fills. See our detailed Rovo comparison.

How is licensing counted?

By concurrent users — active sessions at the same time, not named seats. The 14-day trial allows 10 concurrent users, Team allows 25, Business allows 100, and Enterprise is unlimited. When a user closes their browser, the session expires after 8 hours and frees the seat, so a 40-person org rarely needs a 40-seat license.

Can the AI modify my Jira data, or only read it?

Your choice, per product. The features block in the config has independent read and write flags for Jira, Confluence, and Bitbucket, and everything defaults toward caution. With write enabled, Foxbridge previews each change and asks for confirmation before executing — it never silently mutates an issue.

Can I upload files for the AI to work with?

Yes — drag and drop into the chat. Supported formats are CSV, XLSX, PDF, DOCX, PPTX, PNG, JPG, plain text, and Markdown, up to 25 MB per file and 5 files per message. Typical uses: turning a spreadsheet into Jira tickets one row at a time, summarizing a PDF, or attaching a file to an issue. Image analysis ("what's in this screenshot?") works when Anthropic is the provider.

How do I update Foxbridge later?

docker compose pull followed by docker compose up -d. Configuration and the license cache live outside the container, so updates are non-events.

Read the full setup guide →