---
title: "A Legal Text API Born From a 4,500-Won Spare Server: Serving Statutes to AI Agents"
date: 2026-10-11
time: 22:30
model: admin
category: knowhow
author_type: human
summary: "Sketching out a plan to serve legal text to AI agents from a low-spec spare server. Covers the split between providing source text and making legal judgments, incremental updates, and separating server roles."
tags: legal-text-api,ai-agents,public-data,vps,server,embeddings,search-index,data-service,api-design,incremental-updates
---

# A Legal Text API Born From a 4,500-Won Spare Server: Serving Statutes to AI Agents

When you start hunting for a server to run a homepage, the first thing you start doing is counting costs. How many CPU cores, how much memory, how much storage, and how much the bill comes to every month.

I did the same thing. I compared specs and prices across providers, looking for one that would take a bank transfer instead of a credit card. I wanted an environment where I could manage the monthly operating cost myself rather than letting auto-billing run.

But somewhere in the middle of shopping around, my thinking shifted.

I started out needing a server for my homepage. Later I began to wonder: what if I also set up a separate server just to store data myself and serve it to other AI agents?

That line of thinking is where the legal-text data service came from.

## 1. Do you really need an expensive server to start?

Cost and specs were the first things I weighed.

Running a personal homepage doesn't mean you need a high-end server from day one. The specs you actually need depend on what programs you'll run, how much data will pile up, and how many requests come in from outside.

At the time I also looked at cheap spare servers that could run alongside the main VPS.

One of the candidates I considered looked like this:

| Item | Specs I looked at |
|---|---|
| CPU | 1 vCPU |
| Memory | 1GB |
| SSD | 30GB |
| Monthly traffic | 500GB |
| Monthly cost | about 4,500 won |

Those are the specs and price of the product I was considering at the time. It doesn't mean the same deal is still available now.

With specs like these you're not going to run a large search engine or a heavy AI model yourself. But if the job is scoped clearly — serving static documents, a lightweight API, a small data service — it's a reasonable starting point.

What matters is matching the role of the service to the specs of the server.

## 2. What if I stored the legal text myself?

To look up statute information you can use a public agency's service or query the data through an API.

But thinking about how an AI agent would reference statutes, I realized there was another way to do it.

Collect the public legal text, store it on my own server, and serve the statute originals through an API.

For example, an AI agent requests a specific article of a law, and my server returns the original text. The agent reads the article and uses its own abilities to interpret the content or look into a related question.

The role I had in mind was clear:

**My server wouldn't be making legal judgments — it would be serving the statute originals that AI agents can reference.**

Legal interpretation and judgment stay with each agent. My server handles the source text and the search and lookup functions.

With that separation, even a small server can start out as a fairly simple data-serving operation.

## 3. How would the API be structured?

The basic structure doesn't need to be complicated.

1. Collect statute data from public agencies through their official APIs.
2. Store the original text along with effective dates and amendment information.
3. Make the data findable by statute name, statute identifier, and similar keys.
4. External agents request the statute they need through the API.
5. The server returns the original text plus whatever metadata is needed.

With this setup, no agent has to go hunting for source material from scratch every time. They can query what's already stored on my server.

Of course, having an API doesn't make the data automatically correct. Statutes get amended and effective dates change, so the data's reference point and its freshness need to be tracked together.

When serving statute text, it helps to return the statute name, article number, effective date, and whether it's been amended as distinct fields. That reduces the chance an agent mistakes an outdated article for the version currently in force.

## 4. What changes when you add embeddings?

Once the statute collection grows, just storing files won't be enough to find what you're after.

So one approach I'm considering is using embeddings.

Split the statute documents into sensible chunks and build a vector index, and you can search not just by law name but for semantically related material.

For example, if a user asks for the legal basis relevant to a particular situation, the search system surfaces the articles most likely to apply and hands them to the agent.

That said, an embedding search result isn't a confirmation of legal ground or a legal judgment. Before using it in an actual answer, the original text and effective date of the article still need to be verified.

Legal documents also differ from ordinary documents in that cross-references between provisions and exact wording matter. So it's worth keeping exact-lookup of the original text and meaning-based search as separate capabilities.

The direction I'm leaning toward is storing statute text as the base data and adding embedding search on top as needed.

## 5. What happens when a statute gets amended?

For a legal-text data service, ongoing maintenance matters more than the initial collection.

Statutes keep getting amended, so downloading the data once and leaving it isn't enough.

The plan is to use the official statute APIs to check for statutes that have changed or been added, and update only the data that needs it.

- Collect the original text when a new statute is added.
- Update the content and effective date when an existing statute is amended.
- Refresh the related embeddings and search index when documents change.
- Give API users access to material with the most accurate reference point possible.

This incremental update approach spares you from reprocessing the entire dataset every time.

That said, the actual update method will vary depending on the official API's coverage and terms of use. It's also important to record clearly where the data came from and when it was last updated.

## 6. Separate the roles of the small server and the data-serving server

This brings the server specs question back around.

Storing statute text and serving it through an API is a different kind of job from generating large embeddings or running heavy search processing, and they need different resources.

So rather than trying to do everything on one low-spec server, it's worth separating the roles:

- **Main server:** Runs the homepage and existing services.
- **Data-serving server:** Queries the stored statute text and returns it via the API.
- **Search index:** Set up to run statute searches quickly when needed.
- **Backups:** Preserve the source data, the index, and the configuration separately.

That said, this is a design that separates roles — it doesn't mean every item needs its own physical server. In the early stages you can run several functions on one machine and split them out as actual usage grows.

On a 1GB server in particular, it's more realistic to focus on serving already-prepared data than to also take on heavy embedding generation or large-scale index building.

## 7. Public data services AI agents can use

The interesting part of this idea is that it doesn't stop at just storing the statute data.

If you build an API that serves the data in a consistent format, other programs and AI agents can put it to use.

For example, an agent requests statute text, reads it, then compares related provisions or asks follow-up questions.

The key point here is that my server isn't producing all the answers — it's playing the role of supplying trustworthy source material that other systems can use.

An open API doesn't need to be unlimited. Call limits, caching, access logs, attribution, and terms of service all need to be considered alongside it. Commentary and case law served separately from statute text each have their own terms to check too.

It's worth keeping separate the fact that public data is public, and the conditions under which you can redistribute it.

## Wrapping up: looking for a server led me to a data service

I started out just looking for a server to run a homepage.

I wanted to cut the monthly cost, pay by bank transfer, and get enough resources for what I needed. That naturally led to the idea of a small separate server to store and serve data alongside the main site.

One of the ideas that came out of it was a system that stores statute originals and lets AI agents query them.

You don't need to build a large service from the start. You can begin by accurately collecting public legal text, storing the originals reliably, and serving what's needed through an API.

Once usage and the data volume grow, you can add search or an embedding index and scale the server resources to match.

**Looking for a cheap server isn't just a matter of cutting costs — it's also a matter of thinking about what you can build with limited resources.**

I'm still at the sketching-it-out stage myself. I plan to actually build and run it and see which approaches turn out to be efficient.

And there's one funny thing about it. When someone asks when the legal-text API is coming, I tell them I have to buy a server first. There's no server yet. There's no statute data either. All I have is a 4,500-won idea. Ideas take up almost no storage, so it fits comfortably inside 30GB.