Your server
shouldn't need
ChatGPT.
SSH client with a local AI copilot. Inspect logs, diagnose failures, preview commands, approve fixes. Everything runs on your device. Nothing leaves.
No account required. No telemetry. No cloud dependency.
$ hamma connect prod-api-3
Connected to 10.0.1.42:22 as deploy
› nginx is returning 502 on /api/health
Analysis
Upstream backend (port 3000) is not responding.
Process node (pid 4891) exited 4 min ago: OOM killed.
Proposed fix
risk: mediumsudo systemctl restart node-api
sudo journalctl -u node-api --since "5 min ago" -n 20
✓ node-api restarted. Health check passing.
›
The problem
Every time you paste a server error into a cloud AI, you leak production.
Internal IPs. Routing tables. Database connection strings. Auth tokens in stack traces. Your nginx.confgoes to OpenAI's training pipeline.
In compliance environments, that's a violation. In air-gapped networks, it's impossible. In most teams, it's just Tuesday — because there's no better option.
Meanwhile, SSH clients still assume you already know what to type. You don't need another terminal. You need a terminal that understands what went wrong.
→ AI runs on 127.0.0.1
→ Prompts stay on disk
→ Commands previewed before execution
→ Risk scored. You approve or reject.
→ Works offline. No account. No subscription.
Paste less. Leak less.
Approve every command.
Capabilities
Terminal when you need it. Buttons when you don't.
local ai
AI Copilot
Streaming local LLMs. Diagnoses failures from logs. Proposes commands with risk scores. You approve or reject.
# AI suggests:
sudo systemctl restart postgresql
⚠ risk:low — restarts db service
No "I'd be happy to help."
Root cause. Commands. Done.
ssh
Terminal
xterm-compatible. 256-color. Custom mobile keyboard row. Session reconnect. Scrollback restored.
sftp
Visual SFTP
Browse remote files. Edit in place. chmod, chown, sudo fallback. Syntax highlighting built in.
sys
Docker & Services
Container list. Live logs. Start/stop/restart. systemd units. Process viewer. All without typing docker ps.
vault
Encrypted Storage
multi
5 Platforms
Architecture
No cloud brain required.
AI traffic is hard-locked to 127.0.0.0/8 at the application layer. Not a setting. Not configurable. Your prompts physically cannot reach the internet.
Data flow
┌──────────────────────────────────┐
│ Your device │
│ │
│ Server error / log output │
│ │ │
│ ▼ │
│ HAMMA app │
│ │ localhost:11434 │
│ ▼ │
│ Local LLM (Ollama/llama.cpp) │
│ │ │
│ ▼ │
│ Response → preview → approve │
│ │
└──────────────────────────────────┘
▲
│ Nothing exits this box.
│ Ever.The HAMMA model
Gemma 4 LoRA adapter. Trained on 1,500+ Linux sysadmin failure-solution pairs. Zero conversational filler. Outputs root cause + exact bash commands.
size
5.34 GB (Q4_K_M)
downloads
1,400+ in 48h
categories
39 failure types
hardware
Any dev laptop
$ quickstart
ollama run hf.co/xayrullonematov/hamma-gemma-4-devops-GGUF:Q4_K_M
Approval system
AI proposes. You approve.
The AI can suggest rm -rf /. HAMMA makes that terrifyingly obvious before anything runs.
proposed command
low risksystemctl status nginx
Read-only. Inspects service state.
proposed command
mediumsystemctl restart postgresql
Interrupts active connections. Brief downtime.
proposed command
criticalrm -rf /var/lib/postgresql/data
Destructive. Permanently deletes database files.
Vault
AES-256-GCM encryption. Argon2id KDF. Keys exist in memory only during active SSH session.
Network
AI hard-locked to loopback. No analytics SDK. No crash reporter. Zero bytes leave your device.
Execution
Every command requires explicit approval. Full audit trail. Risk scoring on rm, chmod, iptables, and 30+ patterns.
Workflow
Connect. Ask. Approve. Done.
hamma connect prod
Add server once. Connect with one tap or command.
› why is the API slow?
Describe the problem in plain English. Or paste a log.
[analysis: 3 commands]
AI reads logs, identifies root cause, proposes fix.
[approve / edit / reject]
Preview every command. See the risk score. Your call.
✓ fixed. audit logged.
Execution, output, and full audit trail stored locally.
Nothing runs without your confirmation. Nothing leaves your device.
Who it's for
Built for unstable SSH sessions,
small VPSes, and real server work.
The 3AM server reboot
Your app is down. You're half-awake. You need the right command, not a man page. HAMMA gives you root cause and the fix.
The solo developer
2-5 servers. No DevOps team. You deploy, debug, and maintain everything. HAMMA is the second pair of eyes.
The school server
One Linux box. Student records. No IT department. The teacher who manages it needs buttons, not bash.
The hackathon VPS
48 hours. Fresh server. Nginx won't start. You need answers, not documentation rabbit holes.
The air-gapped facility
Hospital. Government. Research lab. No cloud API calls allowed. AI has to run locally or not at all.
The bad connection
Field deployment. Satellite internet. SSH drops every 5 minutes. HAMMA reconnects and restores your session.
Works where dashboards don't.
Comparison
How HAMMA compares
| Capability | HAMMA | Termius | SSH+ChatGPT | iSH/Blink |
|---|---|---|---|---|
| Local AI (on-device LLMs) | ✓ | — | — | — |
| Fine-tuned DevOps model | ✓ | — | — | — |
| AI loopback enforcement | ✓ | — | — | — |
| Risk scoring before execution | ✓ | — | — | — |
| Works fully offline | ✓ | ~ | ~ | ✓ |
| 5 platforms | ✓ | ✓ | ~ | ~ |
| Visual SFTP + sudo | ✓ | ✓ | — | — |
| Docker & systemd panel | ✓ | ~ | — | — |
| Subscription | Free | Paid | Free | Paid |
| Your prompts go to | Nowhere | Cloud | Cloud | n/a |
Status
Actively developed. Honest about what's done.
Currently in Beta Release Candidate. 860 tests passing. Shipping weekly.
Core Client
shippedSSH, SFTP, terminal, vault
Local AI
shippedInference, HAMMA model, risk scoring
NL Ops
shippedCommand plans, previews, audit log
Built-in Engine
activeNo Ollama dep — ships inside HAMMA
Modules
plannedSwappable specialist adapters
For the server you reboot at 3AM.
Local AI. Zero telemetry. Human-approved execution. Free.
No account. No credit card. No cloud dependency. Just download and connect.