Customer-managed
Deploy Pūnaha in an environment controlled by the customer, with the surrounding infrastructure and operations agreed for that implementation.
Private AI deployment
Choose where Pūnaha runs and which AI it uses
You may need the platform in your own environment. You may prefer a managed cloud service. You may want a local model for one task and an external model for another. Pūnaha keeps those choices open and visible.
Where it runs
Cloud is not the only option
Choose an operating model that fits your environment instead of moving every requirement to fit a cloud-only product.
Separated service pools
Place service pools on customer-controlled infrastructure when scale or isolation requires it.
Windows and Linux
The Pūnaha application supports Windows and Linux environments, subject to the implementation architecture.
One executable, flexible topology
Run all enabled services together or use the same executable for separate control, workflow, AI and browser-facing service pools. MySQL remains separately operated.
Deployment shape
Start together, then separate services when the architecture needs it
| Area | Available shape | What to agree for the implementation |
|---|---|---|
| Application services | All enabled services in one process, or separate control, workflow, AI and browser-facing pools | Service placement, capacity, network paths and operational ownership |
| Data | Three logical MySQL databases for control, workflow and AI concerns | Durability, backup, recovery, credentials and lifecycle management |
| External entry | A same-origin gateway can provide one browser-facing route across separated services | TLS, routing, trust boundaries and failure behaviour |
| Replicas | Durable coordination leases support more than one eligible service instance | Shared storage, identity, admission, readiness and environment acceptance |
| Health checks | Separate liveness and readiness signals | Which dependencies must be ready before an instance receives work |
What stays where
Know where the model runs and where the data goes
Installing software in your environment is only one part of private operation.
Measured local runtime
Pūnaha can test compatible local acceleration and retain separate recommendations for embedding and language-model workloads.
Administrator control
Administrators can keep automatic runtime selection or choose an explicit processor and scheduling policy for the server.
Local vector storage
Keep tenant vector indexes under the customer-managed local data directory.
S3-compatible storage
Select Amazon S3 or a compatible destination for supported vector-index and structured-log purposes.
Azure Blob Storage
Select an Azure Blob destination for supported vector-index and structured-log purposes.
Planned migration
Changing a vector destination does not copy an existing index. Migrate or re-ingest the retained content before switching.
Choose by task
Do not make the whole platform depend on one model
Models are configured separately from workflows, so you can choose a suitable deployment for each job and change it without redesigning the whole process.
Local GGUF models
Run supported GGUF models locally through llama.cpp for tasks intended to stay within the local environment.
OpenAI and compatible APIs
Connect OpenAI or a supported OpenAI-compatible endpoint when that service fits the use case.
Azure OpenAI
Configure Azure OpenAI deployments as an external model option.
Anthropic
Use supported Anthropic models for selected workflow steps.
Google Gemini
Connect supported Gemini models where their capabilities and service terms fit.
Provider-neutral configuration
Refer to configured model deployments from workflows rather than embedding one provider into every process.
Explore connectionsBe clear about the boundary
Private AI is an architecture, not a label
Where the software runs matters, but it does not answer every privacy, security or operational question.
Source permissions, network paths, model endpoints, operational access and retention choices all shape the resulting control boundary.
Pūnaha provides deployment, model, storage and service-topology options. Each implementation still needs an agreed architecture and security review that reflects the organisation's requirements.
Data path
Understand which sources, services and models can receive content at each step.
Operational ownership
Decide who runs, monitors and changes the deployment.
Human oversight
Add approval where automated continuation is not appropriate.
Access boundary
Control which people, groups and services can use each governed resource.
Explore access governancePrivate AI deployment questions
Where does Pūnaha run?
Pūnaha runs on customer-controlled infrastructure. The all-in-one or separated service shape depends on the customer's environment and operating requirements.
Can Pūnaha use a local AI model?
Yes. Pūnaha supports local GGUF model execution through llama.cpp as well as supported external model providers.
Can one workflow use more than one AI provider?
Yes. Different workflow steps can refer to different configured model deployments when the process calls for it.
Does Pūnaha have to run as one application process?
No. The same executable can run all enabled services together or run selected control, workflow, AI and browser-facing services in separate pools. The intended topology still needs environment-specific acceptance testing.
Is Pūnaha described as air-gapped?
No broad air-gap claim is made on this site. A customer-managed implementation can use local models, but the complete architecture must be reviewed for the specific environment.
Show us the environment Pūnaha needs to work within
We can walk through the deployment, model, storage and workflow choices with your constraints in view.