For companies that will not send their work to somebody else's model. We specify the hardware, deploy open models on it, connect them to your systems, and keep the whole thing running - with the evidence trail that makes the decision defensible to a customer, an auditor, or a regulator.
Running your own AI is almost never the cheaper option. A hosted API is subsidised, elastic, and someone else's problem to operate. If cost is your reason, the numbers will probably not support it, and we would rather tell you that now than after the invoice.
Running your own model wins when you have a constraint: data that contractually or legally cannot leave your boundary, a customer who audits where their information is processed, a regulator who will ask, a network with no route out, or a volume so sustained that per-token pricing stops making sense. If one of those is true, the rest of this page is for you.
And if you do have one, it may not require buying hardware. A good share of these constraints are satisfied by running in a cloud account you already own. That is the next section, and it is the cheaper answer often enough that we put it before the one where we sell you a rack.
The thing you actually need is that your work is not processed by somebody else's model. Owning the machine is the strongest way to get that, and for a lot of constraints it is more than you need. Running it inside a cloud account you already own satisfies most of them, costs nothing up front, and can be live this week.
Fastest, no capex, elastic
GPU instances in your own AWS, Azure or Google account. Your project, your VPC, your IAM, your keys, no route to the public internet. No model vendor exists in the path, so nothing is added to your subprocessor register that is not already on it.
Right when: Running this week rather than next quarter, bursty or business-hours load, and no appetite for hardware.
Total control, best at sustained load
The rack, on your floor, as described further down this page. No third party in the path at all, no dependency on a network you do not own, and a fixed cost against a market that keeps rising.
Right when: A clause that names cloud processors, an air-gapped or OT network, a regulator who will ask, or a machine that will be busy most of the time.
The one we recommend most often
Stand it up in your cloud now, prove it on your real data, and migrate onto your own hardware when it arrives. Same stack, same models, same governance - the move is a deployment, not a rebuild.
Right when: Almost anyone facing a twelve-to-sixteen week hardware lead time who does not want to wait a quarter to find out whether this works.
The one you are already in. That is not a dodge, it is the entire logic: a provider already on your subprocessor register, already covered by your existing agreement, already assessed, and already understood by whoever signs off on this. Moving to a cheaper specialist GPU host would add a processor you have no relationship with, which is precisely the thing you came here to avoid.
If you genuinely have no preference: a Microsoft estate usually lands on Azure because identity and compliance boundaries line up, and Google's platform has been the more reliable place to actually get mid-sized GPU capacity. We will deploy to any of the three, and we will say so if the one you want cannot give you the instances in your region.
Somebody will say: the cloud provider could still read it. Mostly they could not - it is your VPC, your keys and your IAM - but they do run the hypervisor, and that is a fair thing to raise rather than wave away.
Where it matters, we deploy on confidential computing instances, which keep the data encrypted while it is in memory and being processed, with the GPU inside the protected boundary. The host operator cannot read it, and the machine can attest to that. It costs a little more and it turns a debate into a document.
One thing cloud does not fix: GPU capacity is scarce there too. An instance type can be unavailable in your region for weeks. It is still far faster than a hardware lead time, but it is not a guarantee, and we would rather you heard that from us.
Governance is identical wherever it runs, and in your own cloud there is a bonus: the account it lives in is something Joopler already grades. The deployment and the environment around it end up in the same evidence trail, rather than the infrastructure being somebody else's problem.
Federal, defence and the contractors who serve them have the hardest version of the constraint this whole page is about. They also have an authorization process that most software has to survive before it can be used at all. The deployment model here sidesteps a good deal of that, for a structural reason rather than a clever one.
FedRAMP authorizes cloud service offerings - a service somebody else operates, that your data travels to. This is not one. The model runs inside your boundary, on your hardware or in your own government-region account, and no data reaches a service we operate. So there is no external service in the data path to be separately authorized: it is a component of your system, assessed as part of your system, the way software installed inside an enclave has always been.
That is not a shortcut around the work. Your system security plan still has to describe it, your assessor still has to look at it, and the controls around it are still yours to meet. What it avoids is the separate, sponsor-dependent, multi-year authorization of a vendor cloud - and it means the evidence we generate lands in your package rather than in ours.
The clearest fit there is. A defence contractor holding controlled unclassified information cannot paste it into a commercial AI service, and NIST SP 800-171 governs where it may be processed and who may reach it. A deployment inside your own boundary keeps CUI inside the enclave you already assess, and produces the access and audit records the assessment asks for.
ITAR and EAR turn a model API call into a potential export the moment technical data reaches a foreign person or an unencrypted foreign-hosted service. Running the model inside your own boundary, on hardware or in a region you control, with US-person access only, removes the question rather than arguing it.
Government regions exist for this: AWS GovCloud, Azure Government and Google Assured Workloads all run the same deployment, in the same shape, inside an accreditation boundary your programme already holds.
StateRAMP, CJIS for anything touching criminal justice information, and student records under FERPA. Same pattern, smaller programmes, and usually a faster decision than federal.
Validated cryptographic modules rather than merely strong ones, because an assessor checks the certificate and not the algorithm. Pinned model versions with recorded provenance, since an open-weight file is a supply-chain artefact and will be treated as one. US-person access only where the programme requires it. And the control evidence expressed in OSCAL, which is the format the assessment machinery is moving to rather than a format we invented.
Joopler does not hold a FedRAMP authorization, and we are not going to let a page imply otherwise. Nothing here should be read as us being on the marketplace. What is true is narrower and more useful: this deployment pattern puts the AI inside a boundary you already had authorized, so the authorization you need is the one you already hold.
If your programme requires the governance platform itself to be authorized rather than the deployment, say so early. That is a real conversation about sponsorship and timelines, not something to discover in a security review.
Sized by how many people are using it at the same moment and what they are doing, not by headcount. Hardware is quoted at build time against current pricing, because that market moves.
roughly 10-25 people on light use
One team, one use case
Proving the thing works on your data before anyone signs a bigger cheque.
roughly 25-75 people on light use
A department that depends on it daily
The first deployment people would complain about losing.
roughly 75-250 people on light use
Company-wide, with uptime expectations
AI has become infrastructure and is now somebody's job to keep up.
the environment sets this one, not the headcount
Air-gapped, multi-site, or under a regulator
The network is the constraint, and 'send it to a vendor' was never an option.
Every size is a fixed-price build plus a monthly managed line. No per-seat licence on the models, because the models are yours.
Two things decide what you need, and they move independently. A thirty-person team running agents all day needs more than a hundred-person firm asking the handbook a question twice a week - and if the first team stops when it stops, they need redundancy the second one does not.
Dial one
Set by how many people are using it at the same moment, multiplied by how heavy each of those sessions is. The difference between the lightest and heaviest work is roughly fivefold.
Looking something up in documents. Short prompts, short answers, and everyone does it at different moments.
Producing real output. Longer responses, held for longer, and steady through the working day.
Multi-step tasks that read, decide and write back. One person can occupy a session for minutes at a time.
Dial two
Set by what happens in the hour it is unavailable. This buys resilience rather than speed, and it is most of the price difference between a department build and a company one.
People go back to doing it by hand for an afternoon. One machine, with a spare part on the shelf.
Work queues up and somebody notices by lunchtime. A warm spare and a same-day swap.
Customers feel it. Two machines, either one able to fail without anyone outside noticing.
Most answers land on one of the four sizes. The ones that do not are exactly the deployments a headcount quote would have got wrong, in one direction or the other.
The accelerator is still the long pole, but as of late 2026 it is no longer the only one. The same AI build-out that makes you want one of these has pulled memory and flash into shortage too, so server RAM and enterprise NVMe now have both a price and a lead time worth watching. A rack server configured new is quoting twelve to sixteen weeks from the major vendors, and longer for some configurations.
So we quote two dates: when you can be running, and when the final configuration lands. Where it makes sense we start you on previous-generation hardware, which is available in days rather than months, then move the workload onto new gear when it arrives. You get to a working system in weeks instead of waiting a quarter to find out whether the thing was worth building.
One honest caveat on that: previous-generation gear is not the bargain it was a year ago. Some 48GB-class cards now resell for roughly what a new one costs, because supply is the constraint rather than age. The parts where the used route still saves real money are the 24GB cards and the older 48GB workstation cards, and we will tell you which bucket your build falls into rather than assuming.
They all have the same shape: a constraint that rules out a hosted API, and a task repetitive enough to be worth automating. If only one of those is true, it is an experiment rather than a deployment, and we will say so.
HR or operations at a firm with a thick internal rulebook
Load: Light. A handful of sessions at once.
A small professional-services team producing templated work
Load: Medium bursts, long outputs, few people at once.
A support team where a person still presses send
Load: Medium and sustained through the working day.
Lending, insurance or benefits - a queue of submissions to be sorted
Load: Heavy. Multi-step, reads attachments, writes back into a system.
An engineering team whose source cannot leave
Load: Heavy, and latency-sensitive in a way the others are not.
A company past the point where any one person knows where things are
Load: Light per request, high concurrency, and spiky at nine in the morning.
Operations teams automating a process end to end rather than assisting it
Load: Heavy, and the one that needs a register, limits and a stop you have actually tested.
Defence suppliers, health systems, law firms, plants with an OT network and no route out
Load: Varies. The constraint sets the build, not the workload.
If none of these is recognisably you, that is worth knowing before anyone writes a quote. The honest answer is sometimes that a hosted API is the right tool and you should keep using it.
The hardware is the easy part. What makes a local deployment survive its first year is everything around it.
Hardware specified and procured, the stack installed, and a named person on the other end of the phone when a driver update breaks something at an awkward hour. Monitoring, patching and model refreshes are part of the monthly line, not a separate conversation.
Every deployment is registered, every request is recorded as signed evidence, and the model itself is inventoried with its version and licence. You went local to be able to prove something. This is the part that proves it.
Retrieval runs against your systems in place. Nothing is copied to a vendor, and nothing leaves the boundary you drew. We can show you the record that says so.
We deploy models whose licence permits what you are actually doing with them, and we tell you which is which. Some popular open models carry usage conditions worth reading before you build on them.
A fixed-price build, then a monthly managed line. No per-seat licence on the models, because the models are yours. These are bands for a class of build rather than a quote for yours, and they are wide on purpose - accelerators, server memory and enterprise flash are all in shortage as of late 2026, so every one of them is confirmed at order rather than estimated.
The bottom of that range is a previous-generation 24GB card, which is usually the right way to start. The top is a current 32GB card at what they cost today.
The spread is one accelerator versus two, and previous-generation versus new. Server memory is now the second-largest line after the GPU.
Two nodes. How many accelerators go in each one drives most of the range, and half a terabyte of server memory per node is no longer a rounding error.
The environment sets the build, so a number before the survey would be fiction.
The AI build-out has pulled memory, flash and accelerators into a genuine shortage. Server RAM and enterprise SSD pricing has multiplied rather than drifted since 2025, and high-VRAM cards have repriced upward mid-generation. A build costs meaningfully more this year than last, and anyone quoting you a number from a 2025 price list is about to have an uncomfortable conversation with you or with their own margin.
It cuts one way in your favour. Hardware you buy now is a fixed cost against a market that is still rising, and the constraint that sent you looking at local AI has not moved. It also makes the pilot-first route more attractive than ever: prove the thing on hardware that is available today before committing to a configuration that quotes at three months out.
Getting the room ready. On a Pilot this is usually nothing. On a Department build it runs a few thousand, and on a Company pair it can reach tens of thousands - enough to matter, and the single most common reason a local AI quote turns into an argument six weeks in. We survey the site before we price the build, and site work is quoted as its own line so you can see it.
A Pilot runs on a normal office outlet, though it is worth knowing what else is on that circuit. A Department build wants a dedicated 20A circuit, and a Company pair is genuine electrical work: dedicated higher-voltage circuits, panel capacity checked, often a subpanel.
Easy to miss: Redundant power supplies fed from one circuit give you redundant supplies, not redundant power. If the second feed matters, it has to come from a second circuit.
Every watt in comes back out as heat. A Department box under load throws off roughly as much heat as a small domestic heater running continuously, and a Company pair needs something like a ton and a half of dedicated cooling - a mini-split sized for the room rather than the building.
Easy to miss: Building air conditioning usually stops at night and at weekends. The machine does not. A room that is comfortable on a Tuesday afternoon can be forty degrees by Sunday.
A Pilot uses the drop that is already there. A Department build needs 10GbE, which often means a new run and a switch that actually has 10G ports. A Company pair needs bonded links and usually its own top-of-rack switch.
Easy to miss: Out-of-band management needs its own drop on its own VLAN. It is the one everybody forgets, and the night you need it is the night the machine is off the network.
Also outside the build price: racking and PDUs where there is no rack, a UPS sized for a graceful shutdown rather than for riding out an outage, and any permit or electrical inspection your jurisdiction requires. None of these are surprises once somebody has walked the room, which is why we walk it first.
The worst place to assemble infrastructure is a customer's building, where the tools are somewhere else and a missing cable costs a day. So we do not. Your rack is built, burned in, configured and loaded in our shop, then delivered as one unit. On site there are two jobs: power and network.
Racked, cabled, labelled and dressed in our shop. Then soaked - thermal and memory stress, GPU load, disk baselines - for days, because a component that is going to fail early should fail on our floor and not in your plant room. Infant mortality is the one hardware risk you can actually design out.
Operating system, drivers, inference stack and the model weights themselves, pre-loaded. Model files are enormous and downloading them over a customer's connection has turned a one-day install into a three-day one more than once. Out-of-band management is configured before the rack leaves us, not after it arrives.
Connect the circuits the survey specified, hand off one or two network ports on the VLAN agreed in advance, and run the power-on sequence. Then a validation script and a signed acceptance test. Hours, not days, and none of it improvised in somebody's comms closet.
Serials, firmware levels, model versions and their hashes, a photo record of the build, and the acceptance results. It is the provenance record an assessor asks for, produced as a by-product of building the thing rather than reconstructed afterwards.
Pilot and Department builds, and estate homes
Around eighteen to twenty-four rack units on castors or floor-fixed. One GPU node, switching, a UPS sized for a clean shutdown, patch panel, and room for whatever else the site already runs. Fits a plant room, a comms closet or a garage.
Company builds and anything with an uptime commitment
Forty-two units. Redundant nodes, redundant power distribution on separate feeds, bonded switching, a UPS sized to the load, and out-of-band management reachable before anything else is.
A Pilot where a rack would be silly
The same stack in a tower, pre-built and burned in the same way. Arrives on a pallet, sits under a desk or in a cupboard with airflow, and upgrades into a half rack later without rebuilding anything.
A populated rack is heavy. A half rack with a UPS in it is a few hundred pounds and a full one is well over a thousand, so it arrives by freight on a liftgate and moves on a pallet truck. Before anything is built we walk the route it has to travel: the delivery approach, door widths, thresholds and ramps, turns, any lift and its rated capacity, and the floor loading where it will finally stand. Heavy items like UPS batteries ship separately and go in on site when the path is tight.
The failure mode of this delivery model is a very expensive object sitting in a driveway because a doorway is two inches too narrow. It has a simple prevention, which is measuring first, and we would rather spend an afternoon doing that than explain it to you afterwards.
There is a second benefit in this market. Because the build happens in our shop against our own stock, we can stage scarce components ahead of your order rather than starting the clock on a twelve-week lead time the day you sign.
Every local AI page assumes a tidy set of documents behind an API. Real businesses are not that. They are a shared drive nobody has pruned since 2009, a line-of-business app with no integration, mailboxes holding all the reasoning, and a room full of boxes. Making that searchable is the hard half of the project, and it is the half we are actually good at.
Filing cabinets, archive boxes, a storage unit, and whatever is in offsite storage nobody has opened in nine years. In legal, clinical, insurance and manufacturing this is not an edge case, it is most of the record.
The most common trap. Scanned years ago with no text layer, so they look digital and behave like paper. Nothing can search them and nobody realises until the search comes back empty.
Twenty years of accumulation, no structure, duplicates of duplicates, and three versions of the contract with no way to tell which one was signed. Indexing this wholesale makes things worse, not better.
Where the reasoning lives. Why the exception was granted, what the customer was promised, who approved it. Also the single easiest way to build an oversharing incident, so it gets scoped narrowly and deliberately.
The line-of-business application from 2011 that runs the company and exposes nothing. Usually solvable with a read-only replica, a scheduled export, or the reporting endpoint the vendor forgot to document.
The part that leaves when a person does. It cannot be scanned, but it can be captured - the questions people actually ask, answered once by whoever knows, become a corpus that did not exist before.
The usual answer is a scanning bureau: put your archive in a van, get files back in a few weeks. For most of our customers that is not available, and for the same reason a hosted model is not available - the records cannot leave the building. So we run the capture on site. A production scanner is provisioned into a room you control, for as long as the backlog takes, and nothing crosses your boundary at any point in the process.
Not an office multifunction. A sheet-fed production unit with ultrasonic double-feed detection and a deep feeder, plus a flatbed for anything fragile or bound, and an overhead unit for volumes and drawings that cannot be unbound. Installed in a room you control, for as long as the backlog takes.
Staples, folds, tears, mixed sizes, sticky notes that are load-bearing. Preparation typically takes as long as scanning or longer, and it is the line most quotes get wrong. Plan on roughly five to eight archive boxes a day per operator all-in, not the number on the scanner's spec sheet.
Recognition with confidence scoring, so a page the engine was unsure about is flagged for a human rather than quietly indexed as nonsense. Handwriting needs a different model again and is materially less accurate - we will tell you which parts of your archive are realistically searchable and which are not.
Document type, date, the party or matter it belongs to, and its sensitivity, captured at ingest. Without that step you have a faster filing cabinet. With it you have a corpus that access control and retention can actually be applied to.
Most archived paper is never retrieved. Digitising a whole basement to make a corpus is the expensive way to find that out. What works: scan the active and high-value material properly, index the rest at box and folder level so it can be located in minutes, and capture individual items on demand when something is actually asked for. You get most of the benefit for a fraction of the cost, and the part you skipped is still findable.
We will size the backlog with you before quoting any of it - measured in linear feet of shelf, which is the only unit that survives contact with a real records room. Roughly a foot of files is two to two and a half thousand pages.
This is the part a scanning bureau will not raise with you. Thirty years of paper contains records you were obliged to destroy years ago, material under legal hold, privileged correspondence, and personal data nobody remembers collecting. The moment it is indexed, all of it is one question away from anyone who can use the assistant.
So retention and classification run before indexing, not after. Chain of custody while documents are out of the cabinet, a decision on which originals must survive the process - wet signatures, deeds, anything notarised - and certified destruction where you choose it. Scanner caches are wiped and verified, because a production scanner holds images too.
The fastest way to cause a serious incident with an internal assistant is to index everything and let everyone ask. HR files, disciplinary records, salary letters, the acquisition folder - all previously protected by being hard to find, which is not a control.
Retrieval respects the permissions of the source, every corpus gets a named owner who decides who may query it, and what a given person can reach is something you can inspect rather than infer. Running it yourself is what makes this enforceable, rather than a setting in somebody else's product that you have to trust.
Capture is scoped and priced as its own project, separate from the build, because the volume varies far too much to bundle. It is also the part most likely to pay for itself on its own: a searchable record has value whether or not the AI on top of it ever earns its keep.
You are reading this page because something in your business cannot be sent to somebody else's model. So the answers below are the ones that matter, and we would rather give them plainly than make your security team drag them out of us on a second call.
No. We deploy open-weight models and we do not fine-tune them on your content. Retrieval is not training - the model reads the relevant passage at the moment it is asked and its weights never change, so nothing is absorbed and nothing can be recited back later. There is one narrow exception, it is the tool-call adapter described below, it learns the shape of a call rather than anything in your records, and it never happens without you asking for it in writing.
No. The model runs on your hardware, retrieval runs against your systems in place, and prompts and answers never transit a third party. There is no inference vendor in the path, which means there is no subprocessor to add to your register and no vendor privacy policy for your counsel to read. That is the whole point of the deployment, and it is the part we are willing to be audited on.
We hold administrative access to a machine that holds your information, so the honest answer is that we could - and pretending otherwise would be the wrong thing to tell a security team. What we commit to instead: named individuals rather than a shared account, access only for a stated reason, and a record of every session that you can read. You should require that of anyone you let near this, us included.
Four things end up somewhere once this is running. Your security team will ask about them in roughly these terms, so here they are in those terms.
On your machine, inside your boundary
Retrieval builds a searchable copy - chunks and embeddings - and that copy is real, so we say so. It sits on the same disk under the same controls as the source, and it is rebuilt or removed when the source changes or goes.
On your machine, for a retention period you set
Kept so a person can see what was asked and what came back, which is what an incident review needs. You choose how long. Set it to zero and the conversation history goes with it, along with the assistant's memory of past conversations.
Metadata only, signed
Who asked, when, which model, which documents were reached, whether policy refused it. Content is never stored, only a hash, so the trail is verifiable without anyone holding the text - including us.
On your machine, unchanged
The open-weight model we deploy is the same file the publisher released. Since we do not train on your content, the weights hold nothing of yours, and you can hash them against the published release to confirm it.
The hardware is yours and so is everything on it. Ending the managed agreement removes our access, not your system - we revoke our own credentials, hand over the administrative ones, and you keep a running deployment. Nothing has to be extracted from us because we were never holding it. Ask any hosted vendor the same question and compare the answers.
A claim about where data went is worth what the record behind it is worth. Every request is recorded as signed evidence, the model is inventoried with its version and licence, and the whole lot maps to the controls an assessor will ask against. When a customer's auditor asks where their information was processed, you answer with a record rather than an assurance.
It is the request we get most often, and it is worth understanding why we will normally talk you out of it.
Fine-tuning teaches a model style, format and vocabulary. It is poor at teaching facts, and worse at teaching facts that change. Train it on this quarter's numbers and you get a model that states last quarter's with total confidence.
Retrieval over your documents, a memory of past conversations, and live lookups into the systems that hold the truth. The model reads the current answer at the moment it is asked, rather than remembering an old one.
One narrow job: teaching a smaller model to call your specific systems reliably. A light tune on your own naming and call patterns turns a model that is nearly right into one you can depend on. That is a real use, and it is the only one we will quote without argument.
Moving the model in-house does not remove the obligations. It removes the vendor who was quietly meeting some of them for you.
Record-keeping duties apply wherever the model runs. With a hosted provider there is at least a vendor log to point at. On your own hardware there is nothing at all unless something is recording it, and the reason you went local was to be able to prove something in the first place.
"Our data never leaves the building" is the sentence that justifies the whole project, and it is the one a customer will ask you to demonstrate. Joopler turns it into a signed, independently checkable record rather than an assurance.
The moment it reads a ticket and writes to a system, it is an agent operating unattended on your estate. It gets a register entry, an owner, declared limits, a trace of what it did, and a stop button that has been tested - the same as any agent you bought.
How agent governance worksWhich weights, which version, which licence, and what any tuning was trained on. Nobody tracks this today, and it is the first thing an assessor will ask once local deployments are common enough to notice. We record it from day one.
The same stack, built for a home: a private assistant that answers in the room you are standing in, controls what is already on your network, and never sends a word of it anywhere. No subscription, no account, no microphone reporting to a platform. It knows who is speaking, which is what lets a child ask for a timer and not for the front door. A genuinely good way to see what local AI feels like before committing a company to it.
Book a demo. Connect your stack. Share auditor-defensible evidence in days, not months.