Teramot – Teramot Docs & Engineering

Eight Rows, Not Twelve Million: The Cache Behind Teramot Beacon

Wed, 16 Sep 2026 00:00:00 +0000

Teramot Beacon answers business questions against live data by pulling only the slice a question needs into an embedded DuckDB, inside the customer’s own network, on any cloud or a laptop. The interesting engineering is not the pull. It is what happens on the second question: a slice registry with a strict containment law, column widening instead of re-pulls, and a cache that is invalidated by the version of the source, never by a timer.

Some of our customers cannot let their data leave the building. Some run on AWS, some on GCP, some on Azure, one on Oracle Cloud, and at least one on a server with a sticker on it. All of them wanted to ask a question about their business in plain Spanish and get a correct number back. That need (on-premise and multicloud) is where Teramot Beacon comes from. This is the story of the part I find most fun: the cache.

Dozens

Rows moved

To answer aggregate questions over fact tables of millions of rows, on real customer data, exact to the cent.

Container

The whole node ships as one image with DuckDB inside. State is a directory. Any cloud, or a laptop.

Source connectors

From Postgres and SAP HANA to Salesforce, Google Sheets, Iceberg on S3 and a CSV somebody emailed.

Days to 1.0

First commit 5 July 2026. Version 1.0.0 tagged 27 August 2026. Three engineers.

1. The two ways of Teramot

Teramot’s promise has always been one sentence: a correct number about your business, without months of data engineering first. There are two shapes to deliver it.

The Teramot way builds the company’s curated data infrastructure and keeps it alive: sources are ingested, cleaned, modelled and served, and every question, dashboard and agent works on top of that map. It is the shape you want when you want to build your warehouse.

The Teramot Beacon way is for the customers whose data cannot leave their perimeter, who run on whatever cloud they already have. A single node runs inside their network, reads the source’s metadata to learn what is there, lets an agent decide which tables, columns and filters the question needs, pulls exactly that into an embedded DuckDB, and writes SQL against the local slice. The answer travels back with its SQL, its row counts per table and a trace. The source only ever sees SELECT statements with bind parameters, and the rows that leave it are the ones the answer is made of.

2. The galaxy-brain ladder

Every engineer who hears “pull only what you need” climbs the same four rungs. We climbed them in about nine days.

The four rungs. The node lives on the bottom one, and this article is mostly about keeping it there on the second question.

The last rung matters more than it looks. For “revenue by region for 2025” the node does not pull the 2025 rows and group them locally. It asks the source to run the GROUP BY and ships back the groups. In our first three-customer test on production data, aggregate questions moved a few dozen rows at most against fact tables of millions. One of those sources was a multi-gigabyte CSV, and the answer matched the customer’s own number to the cent.

The funnel that gets there has eight stages. Two carry this story: decide, where the cache lives, and estimate, which counts the rows a filter would return before pulling them, so the node can refuse, tighten, or push the aggregation to the source.

The eight stages of one question. Everything before pull is metadata and cache. Customer rows move in exactly one box.

3. Then we measured, and felt silly

The obvious optimisation target was the pull. Pulling is I/O, I/O is slow. Then we instrumented nine real runs of the same question against a customer’s data.

The pull was 8 percent of the clock. 78 percent was a language model writing tokens at a steady 123 per second, and most of those tokens were the model thinking, not the final SQL. Making the pull twice as fast would have saved fifteen seconds out of four minutes. The only way to make a repeated question dramatically faster is to not call the model at all. So the cache had to remember more than rows. It had to remember the plan.

4. A cache with a legal department

The cache is a slice registry. Every pull is described by what it asked for: which tables, which columns, which filter, which aggregation. A new question is not hashed and looked up. It is checked for containment: does something we already hold cover what this question needs? And the law is strict.

The containment law in three requests: a hit, a widening, and a miss. A cached slice may never serve fewer rows than the question asked for.

Three outcomes fall out of that law. A hit means the slice already holds everything the question needs and nothing moves. A near-miss on columns is not a miss: it triggers widening, which fetches only the gap and leaves the rest of the slice untouched. In the replay that proved it, widening moved 830 rows where a fresh pull moved 2,985; the commit said “a missing column no longer re-pulls the world”. And anything that would make the slice serve fewer rows than the question asked for, a different filter, a different grouping, is a miss, no matter how tempting the shortcut. We learned the cost of a tempting shortcut from a benchmark question that answered 116 where the truth was 51.

Under the registry sits a plan cache that remembers how a question was answered, not just which rows it needed. When a question comes back and nothing underneath has changed, the answer is recomputed without calling the model at all. A follow-up inside a conversation works on the slice it already has.

The cold number is honest: streaming a multi-gigabyte CSV from object storage takes minutes, and the node says so while it works. The next question on the same data takes about twenty seconds, and a follow-up on a warm slice about the same, with zero reads from object storage.

5. Validate, don’t expire

This is the part I am proudest of, because it is the part where we deleted code.

Our first cache had a TTL of 900 seconds. Fifteen minutes is a perfectly reasonable number to type. It is also completely wrong for how people ask questions about their business.

Nine real runs of the same question, hours apart. The 900-second TTL never hit once. The cache worked perfectly and served nobody.

Nobody:

Absolutely nobody:

The 900-second TTL: expires quietly at 10:15, three hours and forty-five minutes before anyone needs the data again.

The temptation is a longer TTL. That is the wrong fix, because age was never what made a slice invalid. A slice is invalid when the source changed. So the clock was replaced by a source version with two parts, on purpose, because a slice and a plan break for different reasons:

Part	What it fingerprints	What it invalidates
Shape	A fingerprint of the catalog: which tables and columns exist, and their types.	Cached plans. A stored answer against a shape that moved is wrong.
Content	A per-table marker that advances when a refresh actually lands new data. It describes that something changed, never what, so it can never leak a value.	Cached slices of that table only. A hot table does not evict the other nineteen.

The rule that now governs the node, in one sentence from the commit that shipped it: “the clock stops invalidating and starts triggering validation.” A slice serves for as long as it is valid, and age is not part of validity. The cache stays on until somebody refreshes, by hand or on a schedule; a question that cannot tolerate that asks in live mode. Every answer carries the version it was served from. The correct model deleted more lines than it added.

6. ETL at question time

“Pull only what you need” also changed what gets cleaned. An up-front pipeline has to transform every table it ingests, because it cannot know which questions will arrive. Beacon runs its ETL on the slice, and only on the slice: the columns a question selected, the rows that passed its filter, the groups the source returned. If the answer is eight rows, eight rows get typed, normalised and checked. The other twelve million never enter the pipeline, because they never entered the node.

That has two consequences we did not fully appreciate at first. The obvious one is cost: cleaning the fraction of a source that a question touches is cheap enough to do on every question, so nothing has to be pre-computed or kept in sync. The less obvious one is context. When the transformation runs at question time, it runs with the question in hand and the real values in front of it, and whatever it decides is recorded in that answer’s trace. A decision that turns out to be wrong affects one answer, where it can be seen and corrected, instead of being baked into a table that everybody reads for a year.

7. What grew around the cache

A fast, honest answer is the seed. Around it, in about eight weeks, the node grew what a company needs to actually run on those answers:

Organizations and permissions. Members, roles and workspaces, signed in with the company’s identity provider. A results table has an owner and can be shared.
Row-and-column policies, enforced inside the funnel, not in the UI. A slice pulled under one policy is never served under another, so the cache cannot be used to look around a permission.
Dashboards. A saved answer gets a place to live, controls the reader can move, a click that filters the rest, a link to share. As one release note put it, a dashboard stopped being a photo.
Alerts. A monitor watches a results table and speaks first. The organization writes the message, the node owns the words, and no model runs at trigger time.
Bring your own model. The reasoning model is chosen per node, and an organization can bring its own key.

And every answer still carries its SQL, its rows per table and a trace id. Sources are read-only, and budgets refuse before rows are in memory.

8. The milestones

The thin loop
5–6 July 2026
Four repos in one day. The first real commit is the architecture that never changed: harvest → narrow → select → pull → model. Next morning the eval goes from 20% to 25/25, the protocol freezes 1.0, and the first slice cache replays a repeated question 1,274× faster.
Files are sources, and three real customers
14 July
CSV, Excel, JSON, Parquet, buckets and Apache Iceberg in one day, read in situ. The same day, three customers' production data answered exact to the cent with a few dozen rows moved.
Organizations, policies and dashboards
4–13 August
Organizations managed from the product. Row-and-column policies enforced in the funnel. Dashboards land, then bring-your-own-model.
The source-version cache
20 August
Five PRs in a day. The clock leaves the serving path, and every answer says how current it is.
1.0
27 August
v1.0.0: the node has its own assistant and knows what it spends. Fifty-three days after the first commit.

9. What a cache taught me

A cache is a theory about what will be asked next. Ours started as a theory about time, and time turned out to be the wrong axis: nobody asks a business question every fifteen minutes, and nothing about a number becomes false because a quarter of an hour passed. What makes a number false is that the world it described has moved. Once we stopped asking how old is this and started asking is this still true, the code got shorter and the answers got more honest, and I suspect that trade shows up everywhere we build systems that remember things on behalf of people. The other lesson is quieter. We set out to move as little data as possible, and ended up with a node that holds exactly the pieces of a company’s data that somebody, at some point, genuinely needed: small, correct, versioned against their source, and shaped like questions. That is a strange and rather beautiful kind of memory. It knows nothing the business never cared about, and everything it does know, it knows because someone asked. What happens when you let that memory grow on purpose, one question at a time, is the next thing we are building. More on that soon.

— Sol Soletti

How to Get SOC 2 Certified Without Dying in the Attempt

Mon, 14 Sep 2026 00:00:00 +0000

Somewhere in your sales pipeline there is a deal parked behind a single sentence: “we’ll need your SOC 2 report before we can sign.” Nobody on the engineering side asked for this. Everybody on the engineering side is now doing it.

The good news is that SOC 2 is survivable. The bad news is that most teams lose the run in the first ten minutes, during character creation, before a single control has been tested.

3–12

Months of observation

The window a Type II report covers. The part you cannot redo.

1 of 5

Criteria that are mandatory

Security. The other four are opt-in — usually by accident.

Do-overs

March is already in the report. It always was.

1. Type I is the tutorial. Type II is the boss run.

These are not two difficulty levels of the same report. They measure different things.

Type I asks: on this one day, were your controls designed sensibly? It is a photograph of your dojo. You can tidy the dojo the night before. Plenty of teams do.

Type II asks: over the next three to twelve months, did those controls actually operate? It is the whole fight, on tape, including the part where you fumbled.

This is the detail that catches people: the observation window is a roguelike run. There is no save scumming. When the auditor pulls a sample from March and you offboarded someone in March without revoking their access, you cannot go back and fix March. March is done. March is in the report.

2. Your controls are binding vows — so stop making them harsher

In Jujutsu Kaisen, a binding vow grants you power in exchange for a restriction you impose on yourself. The vow is only as strong as it is specific, and once you make it, you are held to it. Whether you meant it that way is not relevant.

SOC 2 controls are binding vows. You write them. Then an auditor spends a year checking whether you honoured your own words.

Which is why the single most expensive mistake in SOC 2 is not laziness. It is enthusiasm. A nervous team writes the most impressive-sounding policy it can imagine, and only later discovers it has signed a contract with its own future self.

The vow you were tempted to make	The vow that survives the run
“Access reviews are performed monthly.”	“Access reviews are performed quarterly.”
“All findings are remediated within 24 hours.”	“Findings are triaged within 5 business days, with severity-based SLAs.”
“Every production change is reviewed by two engineers.”	“Every production change is reviewed by at least one engineer who is not the author.”
“We log everything.”	(delete this, it is not a control, it is a mood)

The monthly access review does not get you a better report than the quarterly one. It gets you twelve chances to fail instead of four. Same power, triple the restriction. That is a bad vow.

Write the weakest vow you can defend, honour it perfectly, and tighten it next year.

3. Character creation: do not pick all five criteria

SOC 2 has five Trust Services Criteria. Exactly one of them is mandatory:

Security — the Common Criteria. Required. This is the run.
Availability — optional.
Confidentiality — optional.
Processing Integrity — optional.
Privacy — optional, and the most expensive of the four by a wide margin.

Selecting all five on your first audit is choosing Ultra Hard on a fresh save file with no New Game+, no gear, and no idea where the checkpoints are. Your customer almost certainly asked for “a SOC 2 report.” They did not ask for Processing Integrity. Ask them before you volunteer for it.

Start with Security. Add criteria in year two, when evidence collection is boring instead of terrifying.

4. The chart every team recognises

Here is the strategy teams instinctively reach for, plotted against what a Type II audit actually samples:

The auditor samples uniformly. That heroic spike in month eleven is worth nothing for months one through ten, because months one through ten are where the sample came from. The dashed line is the only line that matters, and it is flat, which means the work has to be flat too.

5. Domain Expansion: the audit itself

Megumi’s Ten Shadows can only summon what has already been trained. You do not get a new shikigami during the fight. You get the ones you did the work for.

An audit is a domain expansion in the most annoying sense: inside it, attacks land automatically. You cannot dodge a question about March by being excellent in September. You cannot out-argue a missing offboarding ticket. Being genuinely good at security and having no record of being good at security produce the same report.

There is also the manoeuvre every engineer tries exactly once:

“But our cloud provider is SOC 2 certified.”

That is their Infinity, not yours. A vendor’s report covers the vendor’s controls. Yours still has to explain who at your company can reach production, and when you last checked.

6. Where the year actually goes

Every screenshot you take by hand is a control that will fail the moment the person who takes it goes on holiday. Evidence should be a side effect of the system, not a chore appended to it. Access reviews come out of your identity provider. Change management comes out of your pull requests. Vulnerability management comes out of your scanner. If a human is pasting an image into Slack once a month, that control is not automated — it is scheduled, and schedules break.

7. The actual survival kit

Security only, year one. Add criteria later, from a position of boredom.
Weakest defensible vow. Quarterly beats monthly. Always.
Say “not applicable” out loud. No physical datacenter means no physical access control. Write that down instead of inventing a policy about a building you do not have.
One owner with real calendar time. SOC 2 distributed evenly across a team is SOC 2 owned by nobody, discovered in month eleven.
Automate at the source. If evidence cannot be exported from a system, the control is already broken.
Start the window when you are ready, not when the deal is signed. The window is the only part of the schedule you control.

Building Self-Service IPsec Connectivity for External Databases

Fri, 11 Sep 2026 16:50:39 -0300

Teramot extracts data from sources operated by its customers. Some databases live inside private networks and are reachable only through a site-to-site VPN. Connecting them used to require an operator to configure our gateway, create a TCP forward for the database, and give its local port to the extraction worker.

We replaced that runbook with a control plane that stores the requested connection and a gateway controller that applies it. The controller creates the isolated Linux networking resources, configures strongSwan, and reports the resulting state. If the gateway is replaced, its configuration can be reconstructed from the same stored request instead of being rebuilt by hand.

The important change was not automating a sequence of commands. It was making a private connection a state the system maintains. This article explains how we provision and maintain that connection, then how extraction workers use it without gaining unrestricted access to the customer’s network.

1. From a manual runbook to a managed connection

In the original process, an operator exchanged a pre-shared key, configured the Teramot gateway, and set up forwarding for each database endpoint. Operators had to track which network configuration and local ports belonged to each connection. The gateway’s local disk held its configuration, so replacing the machine also meant reconstructing that setup.

A script could automate those setup steps, but running them once would not answer the ongoing questions: does the gateway still match the requested configuration? Which update is current? What should a replacement machine recreate?

We split those responsibilities between a control plane, which stores what should exist, and a gateway controller, which manages the corresponding network resources:

Manual responsibility	Managed replacement
Edit the gateway configuration	Validate and store the requested connection outside the gateway.
Prepare the network environment	Have the controller manage namespaces, interfaces, and routes.
Configure the IPsec connection	Load or update strongSwan through its control API.
Inspect the machine to understand its state	Report the applied configuration and tunnel health.
Rebuild configuration after a gateway failure	Reconstruct the runtime from the stored request.

Self-service describes the Teramot side of this process. The customer-side gateway still needs compatible configuration; storing a request in Teramot does not configure the remote peer. The connection parameters describe the agreement between those two sides.

Using the tunnel is a separate responsibility. The data plane carries database traffic through the provisioned connection. Keeping it separate from provisioning lets a worker use an approved destination without giving it authority to configure the gateway or choose arbitrary destinations inside the private network.

2. How the controller provisions and maintains a tunnel

Consider a customer connecting a private network that contains a database at 10.12.4.20. Before an extraction can reach that database, Teramot needs a tunnel to the customer’s gateway and a routing context for its private network.

The user supplies the peer address, Internet Key Exchange (IKE) identities, approved network ranges, optional private DNS servers, and cryptographic settings. The control plane validates and stores that configuration as desired state: what the gateway should maintain, not a copy of files from the gateway’s disk.

Turning the request into network state

The controller reads the desired state and performs the work previously done on the gateway by an operator:

Ensure the connection’s isolated network namespace exists.
Ensure its Linux IPsec interface (XFRM) and routes match the requested network ranges.
Retrieve the connection’s pre-shared key and load or update its configuration in strongSwan through VICI, strongSwan’s local control API.
Inspect the resulting Linux and IPsec state and report what was applied.

The controller manages the configuration around the tunnel; strongSwan handles negotiation with the remote gateway. Its IKEv2 implementation uses the pre-shared key to authenticate the peers and establish an IKE security association. CHILD security associations then define protection for the approved traffic. The Linux kernel encrypts that traffic using Encapsulating Security Payload (ESP) and its XFRM framework.

We did not build a new IPsec implementation. We built the system that supplies its configuration, manages the surrounding Linux network environment, and connects its runtime state back to the product.

Maintaining state instead of running setup once

The controller repeats this process, fetching the latest desired state and reporting observed state: what actually exists on the gateway. This reconciliation loop also supports recovery. After a restart or instance replacement, the controller reconstructs the runtime from the stored configuration instead of requiring an operator to restore local files.

Updates can overlap in time. If a user changes a connection while an earlier update is still running, the older result must not become authoritative. Each update therefore carries an increasing generation number, which the controller checks before applying or reporting a result.

The controller is also the only component that changes this managed network state. The proxy does not write routes, and operators do not need to edit connection files for ordinary updates. A connection can be updated without restarting the entire IPsec service or interrupting unrelated tunnels.

Credentials follow a different lifecycle from configuration. The controller retrieves a pre-shared key only while configuring its tunnel. Desired-state documents, server images, logs, command lines, and Terraform state do not contain these keys. Certificate files are written only when the runtime starts.

Knowing what “ready” means

Applying configuration does not prove that the remote peer accepted it, and an established tunnel does not prove that a database accepts connections. We report these separately:

Status	Question it answers
Provisioning	Did the gateway apply the requested configuration?
Tunnel health	Is IPsec active?
Source health	Does the database accept connections?

For our example, the gateway may have the correct routes while the remote peer is unavailable. Or the tunnel may be active while the database at 10.12.4.20 is unreachable. A single “healthy” flag would hide the distinction an operator needs to diagnose the failure.

3. Keeping overlapping private networks separate

The controller needs an isolated routing context because private addresses are not globally unique. A second customer may also have a database at 10.12.4.20. In one shared routing table, that destination alone would not identify which customer network to use.

Each private connection therefore gets a network namespace with its own interfaces, routes, DNS view, and XFRM interface:

customer A namespace: 10.12.4.20 -> customer A tunnel
customer B namespace: 10.12.4.20 -> customer B tunnel

The destination must identify both a database and its network context. When a worker requests a connection, the gateway selects that context from a server-side authorization record rather than from a namespace or address chosen by the worker.

We separate privileges along the same boundary:

The controller has the capabilities needed to manage namespaces, routes, XFRM, and the strongSwan control socket.
The connector proxy authenticates and dispatches requests without Linux network capabilities.
A per-namespace dialer opens TCP connections inside its assigned namespace without permission to reconfigure the host or another namespace.

The network-facing proxy therefore does not hold the controller’s authority to change routing or IPsec configuration. Isolation is part of provisioning, not something an extraction worker sets up for itself.

4. Connecting existing drivers to one approved database

Once the tunnel exists, an extraction still needs a way to use it. Our original proxy accepted a destination host and port from the worker. That gave the worker too much control: a compromised worker could request other destinations inside the customer’s network.

The replacement separates three questions: who is connecting, which database they may use, and which isolated network contains it.

Authorizing the destination before opening a socket

When a user associates a data source with a private connection, the control plane creates a source binding. This server-side record stores the network, namespace, database host, and port. The worker receives an opaque reference to the approved source, not authority to supply a different destination.

For every request, the gateway:

Authenticates the worker through mutual TLS (mTLS) and checks that its workload certificate is authorized to use the binding.
Rejects a binding that has expired or been replaced by a newer version.
Resolves the destination and namespace from the stored binding, never from a worker-supplied host and port.
Rejects loopback, cloud metadata, management networks, and addresses outside the approved private network ranges.

The tunnel supplies network connectivity; the binding restricts its use to the approved database. After a restart, the proxy rejects connections until the controller supplies current bindings and trusted certificate authorities. Listening on a port is not enough to start accepting database requests.

Adapting the connection without changing database drivers

Database drivers speak their own database protocol. They cannot first perform Teramot’s gateway authorization exchange and then switch protocols on the same socket. We put that exchange in a local forwarder and give the driver a temporary loopback port.

For each driver socket, the forwarder authenticates to the gateway with a workload certificate and sends the source reference. The proxy validates the request, then asks the dialer in the selected namespace to open the stored database host and port. Once the connection is established, the forwarder relays database traffic.

This is the extraction path after provisioning. The driver sees a local socket; the namespace dialer reaches the approved private database through IPsec.

Existing drivers therefore need no knowledge of namespaces or Teramot’s gateway protocol. Forwarding introduces a TLS naming detail: the local socket is at 127.0.0.1, while a database certificate identifies the real database host. When hostname verification is used, it must verify that logical hostname rather than the loopback address; forwarding is not a reason to disable verification.

5. Recovering the gateway without hiding connection failures

Storing desired state outside the gateway solves only part of recovery. A replacement host also needs the correct software, services, and permissions before the controller can recreate the connections.

Packer and Ansible Core build a versioned Ubuntu image containing strongSwan, systemd services, permissions, and safe defaults. It contains no peer configuration, credentials, or environment endpoints. Terraform deploys the exact image ID and adds environment-specific network and access configuration.

The image restores the host software; reconciliation restores the connection configuration. We promote the same image between environments, and the previous image ID remains an explicit rollback target.

This is recoverability, not uninterrupted availability. The first version has one active gateway, so connections remain unavailable while automated replacement restores it. A load balancer with one target does not provide high availability.

A restored tunnel cannot restore a database session

Even when connectivity returns, the forwarder cannot safely reconstruct an interrupted database session. The database may have an open transaction or may already have returned partial results. Transparently reconnecting and repeating work could duplicate an operation or produce an incorrect result.

Failure point	Behavior
Before the stream is established	Retry only when the failure is known to be temporary.
Authorization, protocol, or certificate rejection	Fail immediately; retrying the same identity cannot help.
After database bytes have crossed the relay	Fail the operation; never reconnect transparently.

An interrupted stream can look like a normal end-of-file (EOF) signal to the driver. The transport layer preserves its first specific failure so operators can see the network cause together with the database symptom. Recovery must restore future connectivity without pretending that an interrupted operation succeeded.

6. What staging taught us

Integration tests start the real proxy and namespace dialer, create Linux network namespaces, and connect through PostgreSQL, MySQL, and SQL Server. They cover different TLS modes, rejected identities, revoked certificates, overlapping private networks, and interrupted streams. These tests exercise the components, but not every interaction in the deployed system.

In staging, we test the complete path from the control plane to an extraction worker. That exposed two failures the isolated tests had missed:

Healthy processes, broken handoff. Both the proxy and namespace dialer were healthy, but Linux permissions prevented the proxy from opening the dialer’s Unix socket. Process health did not prove that the components could communicate.
Unchanged configuration, rejected refresh. The control plane refreshed timestamps without changing the configuration generation. The gateway treated each refresh as a conflicting update and eventually rejected new connections. The test fixtures had not reproduced that control-plane behavior.

These failures are why complete staging extractions are part of release validation before promotion. Component tests establish important properties; an end-to-end extraction checks that the deployed permissions, state exchanges, and data path work together.

Conclusion

The original runbook produced a working tunnel, but left its configuration and recovery dependent on an operator. The new system stores the intended connection outside the gateway, gives one controller responsibility for maintaining it, and reconstructs the runtime when the machine is replaced.

That managed tunnel is only the foundation. Isolated routing contexts distinguish overlapping customer networks, server-side bindings restrict workers to approved databases, and the forwarder keeps existing drivers compatible. Explicit failure behavior and staging validation make the operational limits visible rather than hiding them behind a successful VPN handshake.

IPsec provides the encrypted path. The system around it turns that path into a repeatable capability for Teramot customers.

— Facundo Vivas

References and further reading

strongSwan documentation, including VICI, swanctl, and the charon daemon.
RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2).
Linux network namespaces.
Linux kernel XFRM framework.
Packer documentation.
Ansible Core documentation.
Terraform documentation.

Welcome to Teramot Engineering

Fri, 11 Sep 2026 14:42:16 -0300

Welcome

Welcome to the Teramot engineering blog.

We build a data platform that turns raw, messy sources into governed, queryable tables. Along the way, we run into problems worth writing about: data pipeline design, orchestration, infrastructure, and the occasional production incident that teaches us something.

What to expect

This is where we will share architecture write-ups, postmortems, tooling deep-dives, and the reasoning behind decisions we made so future readers — often future us — do not have to rediscover it from scratch.

More soon.

Welcome to Product Updates

Thu, 24 Jul 2025 00:00:00 +0000

Welcome to the official Teramot Product Updates section. 🚀

Here you’ll find:

✅ The latest updates from our product roadmap
🧩 Announcements of new features and internal tools
🛠️ Guidance for integrating with our APIs and services
🔒 Insights into security and compliance improvements
🧪 Previews of upcoming capabilities for our users

Stay tuned! This space will evolve as we continue opening up the Teramot platform to our clients and developer community.

🧭 This update feed is part of our commitment to transparency, innovation, and user-centric development.