A 10-minute tutorial that covers how we manage servers, store AES-256 secrets, and maintain persistent AI memory in a production environment.
Why this article exists
There are now many different Ai tools out there in the market, various ways of structuring and remembering your data, and levels of control. We have found a hybrid method that is slightly different from the current code tools or cron job agentic AI bots out there.
And one that gives you back time but with complete control.
People who install VEKTOR use it for a number of different reasons; remembering things between Claude sessions is a common one. But that’s also approximately 20% of what the system can do.
The other 80% lives in three capabilities that most users install, glance at, but do not realise the true potential they are holding: the credential vault, the SSH execution layer, and the memory namespace system that ties it all together.
We call the combination hybrid memory — because it describes what’s actually happening. Local SQLite for speed. AES-256 encryption for security. Semantic recall for relevance. SSH approval gates for safety. A credential vault that keeps your secrets out of plaintext and out of your chat history. All of it wired together so that Claude goes from a capable-but-stateless assistant into something that knows your infrastructure, remembers your decisions, and asks before it does anything irreversible.
This tutorial is what we actually do every day. The commands below are the commands running against a real Ubuntu VPS right now in production.
By the end of this you will:
Setup takes about 10 minutes. The habits take a week to form. After that, you won’t want to go back to the old world; it's just too powerful.
The mental model before we touch a terminal
Most people think of AI memory as a chat log. Long-term. Persistent. Searchable.
That’s not what this is.
A chat log is a transcript. It gets longer over time, harder to search, and eventually you’re piping ten thousand words of context into every prompt and wondering why the token costs are what they are. Transcripts don’t age well. They don’t distinguish between a decision you made last week and a half-formed idea you typed at 2am and never followed up on.
VEKTOR Memory treats memory the way it actually needs to be treated:
MEMORY ARCHITECTURE
LAYER 1 — WORKING MEMORY (current session)
The active conversation. Fast, temporary. Cleared on session end.
Equivalent: what's in your head right now.
LAYER 2 — EPISODIC MEMORY (vektor_store / vektor_recall)
Facts, decisions, project notes stored from past sessions.
Retrieved by semantic relevance, not keyword match.
Equivalent: "I remember we discussed this last month." LAYER 3 — SEMANTIC MEMORY (vektor_recall_rrf)
Dual-channel: BM25 keyword + vector search, fused via RRF.
Equivalent: "This reminds me of three other things you've mentioned." LAYER 4 — CREDENTIAL VAULT (cloak_passport)
AES-256 encrypted. Separate subsystem. Never appears in recall.
Equivalent: a locked safe that only opens when you ask for a specific key.
BACKGROUND — REM CONSOLIDATION (vektor_ingest)
Runs between sessions. Deduplicates. Resolves contradictions.
Decays stale facts. Surfaces patterns.
After six months: not 1,000 raw memories. A compressed model of your work.
The credential vault and the memory store are separate subsystems that never cross. Your API keys never appear in a vektor_recall result. Your server topology memories never expose your SSH credentials. This separation is architectural — it's the thing that makes the whole system safe to actually use.
The credential vault (cloak_passport)
The most common security mistake in AI-assisted development: typing secrets into the chat window.
You do it because it’s convenient. You paste your Anthropic API key, your server password, your OAuth token. The assistant uses it. The session ends. The token is now in your chat history, in your browser’s local storage, potentially in training data you didn’t consent to.
cloak_passport exists specifically to prevent this. It's an AES-256 encrypted key-value vault that lives locally on your machine. You set a value once. Every subsequent session, Claude retrieves it by name — and the raw value never touches the chat window.
CREDENTIAL VAULT STRUCTURE
──────────────────────────────────────────────────────────────────────────
┌─────────────────────────────────────────────────────────────────────┐
│ cloak_passport vault (AES-256, local SQLite) │ │ │
│ KEY VALUE (encrypted, never shown in recall) │
│ ───────────────────── ────────────────────────────────────────── │
│ vps-vektor -----BEGIN RSA PRIVATE KEY----- ... │
│ anthropic-key sk-ant-api03-... │
│ x-bearer-token AAAAAAAAAAAAAAAAAAAAAAAAAAq... │
│ cloudflare-token cfut_5I4cpDUqedf6jy... │
│ db-password [encrypted] │ │ │
│ Access: explicit get/set only │
│ Never appears in: vektor_recall, vektor_search, vektor_context │
└─────────────────────────────────────────────────────────────────────┘
Why AES-256 actually means something
AES-256 is the encryption standard used by the US government to protect classified information, and it’s worth understanding why that matters rather than treating it as a marketing bullet point.
The “256” refers to the key length — 256 bits, which means there are ²²⁵⁶ possible keys. To put that number in context: if every atom in the observable universe were a computer running a trillion attempts per second since the Big Bang, you would have checked an almost incomprehensibly small fraction of the keyspace by now.
Brute-force is not a viable attack. The only currently known approach that meaningfully threatens AES-256 is Grover’s algorithm running on a sufficiently large quantum computer — which would reduce the effective security to AES-128 equivalent, still widely considered unbreakable in practice.
We are not there yet.
The quantum computers that exist in 2026 are nowhere near the scale needed to run Grover’s algorithm against a 256-bit key in any useful timeframe. Your credentials are encrypted at rest with a key derived from your passphrase via PBKDF2 — a slow, intentionally expensive key derivation function that makes offline dictionary attacks prohibitively costly even if someone obtains the raw database file.
The practical upshot: if your machine is compromised, your cloak_passport vault is not automatically compromised with it. An attacker who steals your SQLite file gets encrypted noise without your passphrase — and brute-forcing that passphrase is, by design, extremely slow.
Setting up your first credentials
"Store my VPS SSH key as 'vps-myserver' in cloak_passport"
"Store my Anthropic API key as 'anthropic-key' in cloak_passport"
"Store my Postgres password as 'db-prod' in cloak_passport"
Retrieving credentials in subsequent sessions
cloak_passport({ action: "get", key: "vps-myserver" }) What this looks like in practice
Before cloak_passport, a session that needed server access looked like this:
“Here’s my SSH key: — — -BEGIN RSA PRIVATE KEY — — — MIIEpAIBAAKCAQEA…”
After cloak_passport, it looks like this:
“Connect to my VPS and check the nginx error log.”
That’s the entire change from the user’s side. Claude knows where to find the key. The key never enters the conversation, as it is an input from the CLI tool locally. This is not a minor convenience — it’s the difference between a system you can actually trust and one you’re hoping doesn’t leak.
Hybrid memory: sessions that remember
The word “hybrid” here is specific. It means two things running in parallel:
Local storage — your memories live on your machine, in an encrypted SQLite file. Not in a cloud database. Not on our servers. Yours.
Semantic retrieval — memories are indexed as vectors, not just keywords. When you recall something, you get the most relevant memories for the current context, not the most recently typed ones.
The combination means your Claude session can walk into a conversation about your VPS nginx configuration and immediately surface the decisions you made three weeks ago about why port 3001 is proxied that way — without you having to explain it again.
The namespace system
Not all memories are the same. Work decisions shouldn’t mix with personal notes. Project context shouldn’t bleed into another project. VEKTOR uses namespaces to enforce this:
NAMESPACE ARCHITECTURE
──────────────────────────────────────────────────────────────────────────
work:vektormemory → project decisions, architecture notes, deploys
work:trading-bot → separate project, isolated context
private → personal preferences, private context
public → general knowledge, non-sensitive patterns
Query: "what do I know about the nginx config?"
Result: work:vektormemory memories only
↳ private notes: not included
↳ credentials: never included
↳ other projects: not included
──────────────────────────────────────────────────────────────────────────
How to store a memory
"Remember that we proxy port 3001 to vektor-server and
port 3002 to mistral-bridge. Never expose these directly."
vektor_store({
text: "Port 3001 → vektor-server (Node). Port 3002 → mistral-bridge.
Neither exposed directly — always proxied via nginx.",
namespace: "work:vektormemory",
importance: 4,
tags: ["nginx", "infrastructure", "ports"]
})
How recall works across sessions
"What's our port configuration?"
vektor_recall({ query: "port configuration nginx proxy" })
"Port 3001 → vektor-server (Node). Port 3002 → mistral-bridge..."
The REM consolidation loop
Every session end triggers a background process that treats your memory the way sleep treats your brain. It deduplicates redundant entries, resolves contradictions (if you stored “we use OpenAI” and later “we switched to Anthropic”, the contradiction is flagged and resolved), and decays stale facts that haven’t been accessed in months.
The result: your memory store gets better with use, not noisier. After six months, you have a precise, compressed model of your work — not a 50,000-item dump of everything you ever typed.
SSH without fear (cloak_ssh_exec) This is the capability most people are nervous about. Giving Claude SSH access to a production server sounds like something you’d have to be either very confident or very reckless to do.
This is where the HITL (human in the loop) comes in and is built differently from Hermes or OpenClaw derivatives; it is not a cron job loop.
The tier system is what makes it safe:
THE THREE-TIER EXECUTION MODEL
──────────────────────────────────────────────────────────────────────────
TIER: READ
Auto-executes. No approval needed.
Examples: ls, cat, ps, df, grep, curl GET, nginx -t, systemctl status
Risk level: zero. You can't break anything by reading.
TIER: WRITE
Requires your explicit approval before running.
Auto-backs up affected files before execution.
Examples: sed -i, nginx reload, npm install, writing configs, curl POST
Risk level: low-medium. Reversible with the backup.
TIER: DESTRUCTIVE
Requires approval + creates full rollback snapshot.
Examples: rm -rf, DROP TABLE, crontab -r, systemctl disable Risk level: high. But you have a rollback key.
──────────────────────────────────────────────────────────────────────────
Every command is classified automatically before it runs. You never have to decide the tier — the system does it. What you decide is whether to approve the ones that need approval.
Setup: storing your SSH key
"Store my SSH private key for my VPS as 'vps-myserver' in cloak_passport"
cloak_ssh_exec({
host: "your.server.ip",
username: "ubuntu",
keyName: "vps-myserver", ← key name, not the key itself
command: "sudo nginx -t"
})
A real workflow: checking your server
You: "Check the nginx error log on my VPS" Claude:
[TIER: READ — auto-executing] → sudo tail -50 /var/log/nginx/error.log
→ Returns: last 50 lines of errors
[No approval needed. Read-only.]
You: "Fix the SSL certificate renewal cron"
Claude:
[TIER: WRITE — requires approval]
Preview: sudo crontab -e (modifies crontab)
Backup: /tmp/crontab.bak created
→ Waiting for your approval...
You: approve
Claude:
→ Command executed
→ Backup stored at /tmp/crontab.bak
→ Rollback key: abc123 (call cloak_ssh_rollback if needed) Multi-step plans with cloak_ssh_plan
For deployments or larger operations, you don’t approve command-by-command. You approve a plan:
You: "Deploy the new nginx config and reload"
Claude:
[SSH PLAN — 3 steps]
Step 1 (READ): nginx -t (test config) — auto-executes
Step 2 (WRITE): cp nginx.conf /etc/nginx/ — needs approval
Step 3 (WRITE): systemctl reload nginx — needs approval
Approve all? [yes/no]
You: yes
Claude executes in order.
If step 2 fails, step 3 does not run. Backup of nginx.conf taken before step 2.
Rollback key provided.
This is the pattern we use for every VPS change. Not because we don’t trust Claude to make good decisions — it usually does — but because the approval gate forces a moment of deliberate review that catches mistakes before they matter.
How the three systems work together
Individually, each tool is useful. Together, they produce something qualitatively different: an AI session that walks in knowing your infrastructure, retrieves your credentials from a vault, operates your servers safely, and stores what it learned for next time.
Look at it like a hybrid Codex or Claude code session but with gates and it can be used in Claude Cowork as well as a power extension.
Here’s what a real morning session looks like:
Setup: getting started in 10 minutes
Step 1 — Install VEKTOR
npm install -g vektor-slipstream vektor activate YOUR_LICENCE_KEY
Step 2 — Run the setup wizard
vektor setup
vektor activate 09A7R1d5-xxxxxxxxxxxxxxxx
The wizard handles MCP registration automatically. It writes the correct entry to your claude_desktop_config.json. Restart Claude Desktop after it completes.
Step 3 — Store your first credentials
Open a Claude session and say:
"Store my VPS SSH private key as 'vps-main' in cloak_passport"
Claude will prompt you to paste the key. It stores it encrypted. That’s the last time you ever paste it.
Step 4 — Store your first memory
"Remember that my main VPS is at [your IP], runs Ubuntu 22,
and uses nginx as a reverse proxy for a Node.js app on port 3001."
Done. Next session, Claude will know this without you repeating it.
Step 5 — Test SSH access
"Connect to my VPS using the vps-main key and run df -h"
If it works, you’ll get your disk usage back. READ tier — auto-executed, no approval needed. Exactly as it should be. Step 6 — Run your first write command
"Connect to my VPS and add a comment to the top of /etc/nginx/nginx.conf"
You’ll see the approval flow trigger. The file backs up. You approve. The comment is added. A rollback key is issued.
That’s the full loop.
What you have now
Most Claude users are operating with a powerful engine and the handbrake on. They retype their setup every session, paste secrets into chat windows, and run commands without a safety net, once you have configured your skill file, passport keys and given Claude control, it goes to work only pausing if tasks need HITL approvals.
You now have:
A credential vault that keeps your SSH keys, API tokens, and passwords out of chat history—permanently
A memory system that learns your infrastructure, project decisions, and working patterns and recalls them in under 8ms without you prompting it
SSH access with a three-tier approval gate that auto-executes safe commands, requires confirmation for anything that changes state, and creates rollback snapshots before anything destructive
The system compounds. The more you use it, the more it knows. The more it knows, the less you have to explain. The less you explain, the faster you move.
That’s the actual value of a second brain. Not that it stores things. That it means you never have to think about them again.
Access to Jot/Chat notes are also included:
Jot Note Gui
The free skill file is here for anyone to use: https://vektormemory.com/downloads
VEKTOR Memory is available at vektormemory.com. The MCP server, credential vault, and SSH tools are included in every plan.
Generative Ai Tools
AI
Aes 256
Ai Memory
Password Management