Running large language models on your own systems can be a good choice for FileMaker teams that want more control over privacy, infrastructure, and their long-term AI setup. With a local deployment, you do not have to send prompts or business data to outside providers. Instead, you can handle embedding generation, text generation, query generation, and retrieval-augmented generation (RAG) within your own environment.

However, having this control also brings some challenges. Setting up local LLM infrastructure is not a simple add-on for most teams. If you are considering using it with Claris FileMaker, here are some important factors to keep in mind before you begin.

 

Understand what “local” actually needs to support

A local AI model server isn’t just responsible for chat responses. Depending on your architecture, it may manage several distinct workloads:

• Text generation
• Query generation
• Embedding generation
• Retrieval-augmented generation (RAG)

Embedding generation and RAG add additional tasks for your AI system. Rather than merely creating responses, the system might need to convert source content into vector embeddings, store or search those embeddings, identify the appropriate context, and then deliver a well-supported answer. This requires more computing power and increases the chances of slowdowns or errors.

Therefore, when you move beyond simple prompt-and-response tasks, you are not just running a model on your system: you are managing a full AI service layer.

 

Separate the AI Server from FileMaker Server

A critical requirement is to keep your AI Server separate from your FileMaker Server.

There are several reasons why this separation is vital. First, LLM and embedding tasks can consume substantial resources and may be unpredictable, especially with multiple users. If these processes compete with FileMaker Server for CPU, memory, or disk space, your main application could slow down or even crash.

Second, separating the AI layer simplifies scaling and troubleshooting. If the model server requires more GPU, memory, or adjustments, you can implement those changes without affecting your primary FileMaker environment. Additionally, if the AI service encounters issues or needs maintenance, it won’t bring down your entire system.

For most real-world deployments, treating the AI layer as an independent service rather than just an add-on to your database server is advisable.

 

Plan for significantly more infrastructure than expected

Many assume a local LLM setup will operate efficiently on basic hardware, but our testing shows this isn’t true once embedding generation and RAG come into play.

These tasks demand substantial processing power. The smallest server that reliably handled our workload included:

• 4 NVIDIA T4 GPUs
• 48 vCPUs
• 192 Gb of memory

This is considerably more than most FileMaker teams anticipate when thinking about ‘local AI.’ Planning your infrastructure early is crucial, especially before your team begins building features requiring local inference.

If you plan to implement features such as semantic search, knowledge retrieval, internal document Q&A, or other RAG-based tasks, hardware sizing must be considered up front. This decision is essential for assessing project feasibility.

 

Do not underestimate hosting costs

Hosting your AI locally may reduce reliance on external vendors, but it doesn’t necessarily save money. Based on the server profile above, AWS hosting costs were about $3,000 per month during our tests. This figure alone should prompt serious business discussions.

For some organizations, privacy, control, and compliance benefits justify the expense. For others, a managed model provider might still be the preferred choice.

The key question isn’t whether local hosting is cheaper than API calls; it’s which cost structure aligns best with your usage, risk appetite, and technical capabilities.

 

Think beyond setup; focus on operations

Establishing a local model server is only the initial step. To be truly ready for operational use, you must also consider:

• Monitoring and alerting
• Model lifecycle management
• Capacity planning
• Security hardening
• Backup and recovery strategies
• Update procedures for embeddings, source documents, and retrieval pipelines

This is particularly critical if your FileMaker users depend on the system for essential business tasks. A setup that works smoothly in testing but is difficult to maintain in production can become more of a hindrance than a help.

The new admin console capabilities significantly simplify deployment, making it easier for teams to experiment and set up initial configurations. However, ease of setup doesn’t equate to reduced complexity overall. While the interface streamlines deployment, infrastructure needs, especially for embeddings and RAG, still require careful planning.

 

In practice, the admin console enables quicker proof-of-concept development, but careful planning for performance, service separation, and overall cost remains essential.

 

Conclusion

Local LLMs for Claris FileMaker are an excellent option if privacy, control, or internal knowledge workflows are priorities. They allow you to handle embedding, text, query generation, and retrieval-augmented tasks without transmitting sensitive data externally.

However, operating these systems isn’t straightforward. Once embedding and RAG workflows are involved, more powerful hardware, higher operational costs, and clear separation between the AI Server and FileMaker Server are necessary.

For teams considering this approach, the critical question isn’t just “Can we run local models?” but “Do we have the right technical, financial, and operational setup to manage them effectively?”

Teams often ask for “an online form,” but that usually isn’t what they truly need.

What they really need is a workflow that collects information, checks it, sends it to the right place, adds details, updates records, and shows the current status to the right people.

This is why Claris Studio stands out when you see it as more than just a web form tool. You can share Studio forms with your team or anyone who has the link. Claris presents Studio as a platform for collecting, viewing, and analyzing data, which can also be used in custom apps.

For many implementations, the strongest pattern is:

• Studio for capture
• FileMaker for business logic and system-of-record behavior
• Connect for orchestration and cross-system flow

A practical use case: vendor onboarding intake

Vendor onboarding is a good example because it has all the right ingredients:

• external submission
• inconsistent source data
• duplicate risk
• internal review
• approvals
• status tracking
• follow-up tasks

That makes it better than a trivial demo.

The target architecture

Here is the core pattern:

External submitter

   ↓

Claris Studio form

   ↓

Claris Connect flow

   ↓

FileMaker

– validation

– dedupe

– vendor creation or update

– review tasks

– status management

   ↓

Claris Studio views/hubs

– intake queue

– review queue

– status visibility

This setup works well because Studio is great for easy, web-based data capture, while FileMaker is better for handling records and enforcing processes. Connect links the two when you need to move, change, or automate data.

Two valid data ownership models

Before building anything, decide where the real record begins.

Model 1: FileMaker-first
The Studio form writes into a FileMaker-connected data source, and FileMaker is the source of truth from the start.

Model 2: Studio-first, then promoted to FileMaker
The Studio form creates a Studio-side record first, and Connect later transforms that submission into operational records in FileMaker.

Both models can work. However, if your workflow involves important business data like vendors, clients, orders, or compliance records, starting with FileMaker is usually the safer choice for the long term.

Why Connect should be treated carefully

Claris Connect can be useful here, but the boundaries matter.

The Claris FileMaker connector works with hosted FileMaker apps and requires at least FileMaker Cloud or FileMaker Server 21.1.0. Claris also points out that the connector does not yet support direct access to Claris Studio tables. So, you should not expect one connector to handle every type of data in the same way.

Claris also documents that when working with FileMaker through Connect, the target app must have both Data API and OData privileges enabled, and those services must also be enabled on the host.

Details like this are important to highlight in a real implementation guide.

Design the schema before the form

A common mistake is building the intake form first and only later figuring out how the data fits into the system.

It’s better to define the operational schema before anything else. For a vendor onboarding workflow, a basic structure might be:

Intake_Request

– RequestUUID

– SubmittedAt

– SubmittedByName

– SubmittedByEmail

– CompanyNameRaw

– TaxIDRaw

– RequestType

– RawPayloadJSON

– ProcessingStatus

– ProcessingError

– RelatedVendorUUID

 

Vendor

– VendorUUID

– LegalName

– NormalizedTaxID

– PrimaryEmail

– Status

– CreatedAt

 

VendorContact

– ContactUUID

– VendorUUID

– FullName

– Email

– Phone

 

ReviewTask

– TaskUUID

– RequestUUID

– AssignedTo

– TaskType

– TaskStatus

– DueDate

 

StatusHistory

– HistoryUUID

– RequestUUID

– OldStatus

– NewStatus

– ChangedAt

– ChangedBy

Two fields here matter more than they may seem:

RawPayloadJSON gives you an audit-safe copy of exactly what came in.

ProcessingStatus and ProcessingError help you track the workflow, which is important when something goes wrong.

Build the Studio form for clean capture, not maximum data collection

Once you have the schema, designing the form gets easier.

A good intake form doesn’t try to gather every detail. It collects just enough clean information to start the process, leaving space to add more details later if needed.

That usually means:

• Prefer controlled values over free text where possible
• Separate public-facing labels from internal field naming
• Avoid exposing operational fields on the intake form
• Collect enough to deduplicate and route, not enough to re-create the entire back office

Studio forms can be shared broadly, including with anonymous users via a link, which is why form discipline matters.

A useful Connect flow pattern

Here is the shape of a practical flow:

Trigger: New intake record created

   ↓

Validate required fields

   ↓

Normalize values

– trim whitespace

– normalize email case

– strip punctuation from tax ID

   ↓

Check for existing vendor

   ↓

If vendor exists:

   update/attach to existing

Else:

   Create new vendor

   Create primary contact

   Create review task

   ↓

Write result back to intake record

– processed

– needs review

– duplicate found

– error

The real technical value isn’t in the visual flow, but in clearly separating each step.

Validation is not the same as normalization.
Normalization is not the same as deduplication.
Deduplication is not the same as approval.

The clearer you make these boundaries, the more reliable your workflow will be.

A FileMaker script parameter pattern worth using

When Connect or another process hands work to FileMaker, JSON parameters are usually cleaner than trying to overload single text parameters.

For example:

{

 “requestUUID”: “2C8A0A6E-85A3-4C3C-A8C0-41F9A88D4E10”,

 “submittedByEmail”: “ap@vendorco.com”,

 “requestType”: “New Vendor”,

 “source”: “Claris Studio”

}

Then the receiving FileMaker script can parse predictably:

Set Variable [ $requestUUID ; JSONGetElement ( Get ( ScriptParameter ) ; “requestUUID” ) ]

Set Variable [ $email       ; JSONGetElement ( Get ( ScriptParameter ) ; “submittedByEmail” ) ]

Set Variable [ $type        ; JSONGetElement ( Get ( ScriptParameter ) ; “requestType” ) ]

Set Variable [ $source      ; JSONGetElement ( Get ( ScriptParameter ) ; “source” ) ]

This isn’t advanced code, but it’s a reliable habit for implementation.

A dedupe pattern that is better than exact-match thinking

Relying only on exact matches is rarely enough for intake workflows.

A more useful pattern is to check some combination of:

• normalized company name
• normalized tax ID
• primary email domain
• known aliases or alternate names

This approach helps you handle different outcomes more effectively:

• exact match, attach to existing
• probable match, send to review
• no meaningful match, create new

This is where FileMaker really proves its value. When cross-record logic is important, it’s best to keep the decision-making in the FileMaker app.

Make the workflow idempotent

This is one of the most practical lessons to include because many “working” intake flows fail here.

Never assume a submission is processed exactly once.

A safer design includes:

• a stable external submission identifier
• a processed timestamp
• a processing status field
• a retry-safe script or flow path
• duplicate detection for the intake record itself

That way, if a flow retries or a user resubmits, the system can recognize the event without creating a mess.

Status visibility matters almost as much as capture

Once the workflow runs, Studio becomes useful again as the visibility layer.

You can create views or hubs that show:

• Unprocessed intake
• Duplicate review queue
• Vendor setup in progress
• Awaiting approval
• Completed onboarding

That creates a much better operational surface than an email chain or a spreadsheet export.

Security and access notes

If you are using Connect with FileMaker, Claris documents that both Data API and OData access must be enabled appropriately. OData is a REST-based standard for querying and updating hosted FileMaker data, and the general OData workflow includes finding and modifying records, as well as running FileMaker scripts via API calls.

That does not mean every intake workflow should become an API-heavy project. It means your architecture should be intentional about privileges and integration points.

Closing thought

The right way to frame a Studio intake project is not, “How do we put a form on the web?”

It is, “How do we build a reliable intake pipeline?”

Studio gives you a clean web-facing start.

FileMaker gives you durable logic and operational control.

Connect gives you orchestration when the workflow needs to move, transform, or notify.

That is the version readers can actually implement.