Feature request: Optional source code inspection and configurable log context for AI log analysis

What problem will this feature address?

The AI log analysis feature currently sends only the last 200 log messages to the selected LLM, along with a prompt asking for a summary, issues, a likely root cause, and suggested fixes. It cannot inspect the application's source code, so it may identify symptoms without enough context to find the underlying issue.

This affects both deployment/build failures and runtime/container errors. The fixed 200-line limit can also omit useful context and cannot currently be adjusted in AI settings.

Describe the solution you'd like

Add the following settings to the AI settings page (/dashboard/settings/ai), applying to both deployment log analysis and runtime log analysis:

1. Enable source code inspection — an opt-in toggle, disabled by default, allowing the AI agent to read the relevant application's source code alongside its logs. The agent should be able to inspect relevant files, follow errors or stack traces into the code, and use that evidence to identify the underlying issue and suggest a fix. Analysis should reference the files and line numbers supporting its findings where possible. Code access should be read-only and scoped to the application being analyzed; enabling this feature should not authorize code changes or command execution. Make clear in the settings that relevant code will be sent to the selected AI provider. When source code is unavailable, explain the limitation and continue with log-only analysis.
2. Log lines sent to AI — a configurable positive integer with a default of 200. Use this value to select the most recent log lines supplied to the LLM for both deployment and runtime analysis, regardless of whether code inspection is enabled. Persist the setting and show the actual line count in the analysis UI. Validate the value and clearly communicate any provider/context-size limit that prevents using the requested amount.

Expected behavior:

• With source inspection disabled and the line limit at its default, existing log-only behavior is preserved.
• With source inspection enabled, both deployment and runtime analysis can correlate logs with the relevant source files, ideally from the revision associated with the deployment being analyzed.
• Changing the line limit in AI settings affects both log analysis entry points; neither remains hardcoded to 200 lines.
• Findings distinguish evidence from the logs/code from an inferred cause.

Describe alternatives you've considered

Manually copying logs and relevant source files into an external AI chat, or manually investigating the files mentioned in errors and stack traces. These require switching tools and assembling context by hand. Increasing the hardcoded limit alone would provide more logs but would not give the AI access to the code needed to investigate the cause.

Additional context

Relevant implementation locations in the current checkout:

• apps/dokploy/components/dashboard/docker/logs/analyze-logs.tsx: shared analysis UI; currently uses MAX_LOG_LINES = 200 and sends log text plus build/runtime context.
• apps/dokploy/server/api/routers/ai.ts: analyzeLogs currently calls generateText with only a log-analysis prompt, without source-code retrieval or tools.

Will you send a PR to implement it?

Not decided.

Start with apps/dokploy/components/dashboard/docker/logs/analyze-logs.tsx to trace the current 200-line selection and settings UI, then inspect apps/dokploy/server/api/routers/ai.ts and its analyzeLogs flow. Determine how both deployment and runtime analyses can receive persisted settings and safely scoped, read-only source context. Done means validated settings affect both entry points, the UI shows the actual count, and analysis distinguishes log/code evidence from inferred causes.