Your palm vein project.
A clearer path
to deployment.
Understand the licence, server architecture and support behind your rollout. Practical answers for banks, fintech teams and system integrators.
From a 10,000-user MVP to a larger private-server deployment.
Capacity and validity.
Two different questions.
A temporary evaluation licence and a purchased licence have different terms. Choose the route that matches your project stage.
Evaluate the small-model workflow on your own server. Hardware, infrastructure and application integration are separate.
No periodic licence renewal is needed to retain purchased user capacity. Additional capacity and services are assessed separately.
For customers who place an initial order of 100 devices and sign a strategic cooperation agreement. Deployed on their own private server.
Registered users determine licence usage. Deleting a user frees capacity for a new registration. For the temporary large-model trial, an expiry notification is provided three days in advance; expired authorisation causes requests to be rejected with an exception and error code.
Restricted network?
Prepare deployment
on your terms.
The large-model algorithm can run on your own infrastructure. Offline installation documentation helps your IT team prepare resources in advance.
Offline installation is not terminal offline matching. Server-side recognition still requires a connection between your application, backend and algorithm service.
Confirm the environment
Review server resources, network restrictions and the intended deployment architecture.
Prepare approved resources
After purchase of the large-model deployment package, use the supplied resource configuration list to download required charts and images in advance.
Transfer and deploy
Move resources into your approved environment or private registry, then configure and validate services.
Take operational ownership
Your team manages infrastructure, access, monitoring and backups after deployment.
Build for your users.
Leave room to grow.
Start with the number of registered biometric users, then assess matching workload, server resources and availability requirements.
Registered IDs are not transaction counts. The guidance here is a planning starting point, not a guaranteed performance specification.
Your servers.
Your operational control.
Free remote deployment support is available for the large-model algorithm. Agree the access method and scope with your infrastructure team before installation.
- Environment checks and deployment typically take 2-3 days.
- Kubernetes deployment requires cluster-admin permissions.
- No continued supplier remote access is required after deployment.
- The algorithm deployment has no external connections.
The schedule covers algorithm deployment, not the development of your entire application or payment platform.
A clear handover.
A defined support route.
Close temporary access according to your internal procedures after deployment. Your team operates the environment.
For later case analysis, provide the relevant case images and error information through your approved data-handling process.
Application development, cashier integration and backend redesign are separate workstreams. Share requirements and deliverables so scope, timing and commercial terms can be assessed.
Plan the transition.
Protect the recovery path.
Small-model and large-model services are independent. The same terminal application can support both during transition, with the required integration.
Move identifiers deliberately
Validate the large-model flow
Test registration, matching and the connection to your business accounts before switching production traffic.
Update account bindings
Replace small-model featureId bindings with the corresponding large-model user_id mappings. Retain required RGB and IR source images for migration; assess re-enrolment if they are unavailable.
Retire the old environment
Stop business requests to the small-model service, then securely delete old biometric data under an agreed retention and deletion process.
Prepare large-model backups
| Component | Recommended starting policy |
|---|---|
| PostgreSQL | Base backup every three days; first backup immediately |
| WAL archive | Continuous archiving with a 30-day recovery window |
| Milvus | Align regular backups with the PostgreSQL schedule |
| Recovery test | Validate full restoration in your own environment |
A cluster is not a substitute for backups. Restoration time and acceptable data loss must be established through project-specific recovery testing.
Questions before
the first rollout.
Search the topics your technical, commercial and operations teams need to resolve.
No matching questions. Try "licence", "server" or "migration".
Bring your requirements.
Define the next step.
Tell us what you are building, who will use it and which integration work your team needs help with.