Enterprise-grade on-premise PaaS by TechRajendra® — hyperscaler capabilities on your hardware, with seamless AWS & GCP hybrid integration. Zero Trust. RBI/SEBI/DPDP compliant. Your data. Your rules.
AravaliStack is installed in your infrastructure. Your team takes over. The platform handles everything in between.
Every enterprise we've spoken to has the same problem. The cloud bill keeps rising. The dependencies multiply. And somewhere, someone important is asking: do we actually own any of this?
Too often, the answer is no. Infrastructure rented. Security bolted on after the fact. Audit trails dependent on vendor support tickets and hope.
We believe every enterprise deserves to own its infrastructure — not rent it, not depend on a vendor's roadmap, not be surprised at invoice time.
We believe security is not a layer you add. It is the foundation you build on. Zero trust is not a product feature here. It is the first principle.
The Aravali mountains have stood for over a billion years. We build infrastructure with the same intention. Permanent. Layered. Yours.
Not an assembly kit. Every capability is designed from day one to work with every other — zero-trust threading through all six.
Click any domain to explore what lives inside it — and how it connects to the others.
| Capability | AravaliStack | OpenStack Providers | Bare Metal Providers | Public Cloud |
|---|---|---|---|---|
| Zero-Trust at Every Layer | ✓ | ✗ | ✗ | Add-on cost |
| GitOps-Native Control Plane | ✓ | ✗ | ✗ | ✗ |
| Self-Hosted ML/AI Platform | ✓ | ✗ | ✗ | Vendor-locked |
| Per-Tenant Cost Attribution | ✓ | ✗ | ✗ | Complex tooling |
| Built-in Developer Portal | ✓ | ✗ | ✗ | ✗ |
| Predictable Monthly Pricing | ✓ | ✓ | ✓ | Never |
| Full Data Sovereignty | ✓ | Depends | ✓ | ✗ |
| Edge-Native Workloads | ✓ | ✗ | ✗ | Limited |
| Consideration | AravaliStack | DIY Platform (30+ tools) |
|---|---|---|
| Time to first production workload | ✓ Weeks | 6–18 months |
| Team required for platform engineering | ✓ 1–2 people ops | 8–15 FTE minimum |
| Inter-tool security integration | ✓ Pre-built | Custom for each pair |
| Upgrade management | ✓ Managed by AravaliStack | Your team's problem |
| Documentation & runbooks | ✓ Full architecture documentation included | Must write from scratch |
| Zero-trust across all tools | ✓ Architecture-enforced | Manual, per-tool integration |
| Cost attribution out of the box | ✓ Platform-native | Separate tooling project |
| Support & accountability | ✓ Single vendor | Community forums per tool |
AravaliStack's architecture aligns with major compliance frameworks by design — not as a configuration afterthought.
AravaliStack curates and integrates 60+ open-source and enterprise tools — configured, secured, and maintained as one coherent platform. No assembly required.
Engineering leaders who chose ownership over dependency.
Join the enterprises that have stopped renting their stack and started owning it.
AravaliStack gives enterprises everything public cloud offers — self-service, elasticity, ML — without giving up ownership, audit trails, or cost predictability.
AravaliStack is live in production across banking, healthcare, government, and technology enterprises in major Indian metro clusters — with air-gapped and on-premise deployments in regulated environments.
A 6-minute walkthrough: from zero to a multi-tenant, GitOps-managed, zero-trust sovereign cluster. Real commands, real output, no slides.
Every transaction auditable. Every access logged. Every policy version-controlled. PCI-DSS and RBI regulatory readiness built into the architecture — not assembled with consultants after the fact.
Regulators want to see who accessed what data, at what time, with what authorisation. AravaliStack makes that answer immediate — always.
Speak with our financial services architecture team.
HIPAA capability without building a separate compliance stack. Full access controls, audit trails, and encryption — built into the platform architecture, not bolted on afterwards.
Every organisation managing patient information faces the same challenge: highly sensitive data, demanding regulatory environment, and severe consequences for any breach or audit failure.
AravaliStack doesn't offer a HIPAA-compliance service layer. It offers a platform where the architecture itself enforces the controls regulators require.
"The question regulators ask isn't 'do you have a firewall?' It's 'can you show me every person who accessed patient record #8473 in the last 18 months, and the authorisation that permitted each access?'"
AravaliStack answers that question before it's asked.
Speak with our healthcare solutions team.
A complete ML environment — training, versioning, notebooks, inference — running entirely inside your own perimeter. Your IP stays yours. Your results stay private.
When you train on hyperscaler ML services, your proprietary data — the training set representing years of competitive advantage — traverses their infrastructure. Their terms govern it.
AravaliStack gives ML and research teams a complete, self-hosted alternative with none of the capability compromise.
Replace public cloud for internal workloads without losing capability. Multi-tenant, self-service, with a developer portal that makes internal cloud feel modern — not like a step backward.
Unpredictable billing. Teams spinning up resources with no governance. No internal showback. Data leaving your perimeter for every ML workload. AravaliStack solves these without asking your engineers to give up anything.
For government and public sector organisations, data residency, auditability, and full operational control are mandated — not optional. AravaliStack is purpose-built for these requirements.
Government agencies cannot afford ambiguity about where data is stored, who can access it, or what software runs on their infrastructure. AravaliStack is 100% self-hosted, fully auditable, and provides complete visibility into your infrastructure.
AravaliStack runs Kubernetes across both OpenStack VMs and Proxmox bare metal simultaneously — workload flexibility without vendor dependency.
AravaliStack runs on a dual compute substrate. Both managed through a unified control plane, with workload placement determined by your policies.
AravaliStack deploys and manages Kubernetes clusters across both substrates. Each tenant receives isolated namespaces with hard resource quotas.
Backup and DR are configured declaratively — your recovery objectives become policy, the platform enforces them continuously.
Every connection authenticated. Every access authorised. Every decision logged. From the first packet to the last billing entry — zero trust enforced at every layer.
AravaliStack assumes the opposite of perimeter security: no connection — internal or external — is trusted until explicitly verified at every layer.
A unified identity fabric spanning your entire infrastructure — powered by Keycloak (SAML/OIDC/SSO), Ory Hydra (OAuth2 server), Ory Keto (fine-grained permission engine), and Ory Kratos (identity management). The same stack enterprises like Société Générale and Mistral run — on your hardware.
As autonomous AI agents become part of enterprise workflows, they need to authenticate, authorise, and be audited — just like human users. AravaliStack extends its identity fabric to non-human actors: services, agents, and automated pipelines all get verifiable identities.
Stytch, WorkOS, and Okta all offer M2M auth — as cloud services. Your data on their servers. AravaliStack gives you the same capability, with the same developer experience, entirely on your own hardware. Your agents' authentication events never leave your perimeter.
All security policies are declared as code, reviewed in pull requests, and enforced automatically. Policy changes have the same review process as application code changes.
From real-time streaming to model training to edge inference — a complete data and AI platform that never requires your data to leave your perimeter.
Replicate and Hugging Face Inference API let developers run models with a single API call — but the inference happens on their servers, and your sensitive data travels to their infrastructure. AravaliStack gives you the same developer experience, entirely on your own GPUs.
Deploy any Hugging Face model, any custom-trained model, or any fine-tuned checkpoint to your AravaliStack GPU cluster. Serve it through a standardised REST API. Your data never leaves your perimeter.
Axiom reimagined observability for AI engineering — prompt tracing, cost attribution per LLM provider, and agent workflow visibility. AravaliStack ships this capability natively, on your infrastructure, with zero-sampling log retention.
End-to-end OpenTelemetry tracing across your entire application stack — services, databases, queues, and AI inference calls — in one unified trace view.
Trace every LLM call, every agent step, every tool invocation. See prompt → response → cost per call. Debug agent loops. Identify which prompts are driving latency or cost spikes.
Per-team, per-project, per-model token consumption tracked in real time. Set budget limits on AI inference spend. Alert before a runaway agent loop becomes a ₹10L bill.
Axiom built its reputation on one claim: never sample your logs. AravaliStack's observability layer uses a columnar log store — every log line retained, queryable at any time, at any scale. No data loss, no "we sampled it out."
For regulated environments — RBI, IRDAI, SEBI — this isn't just useful. It's the answer when the auditor says: "Show me every authentication event from March 2024."
Track model drift, accuracy degradation, and latency SLAs over time. Compare model versions. Roll back to previous checkpoints when production performance degrades.
Self-service provisioning, browser-based IDE, automated testing, and integrated documentation. When the platform is good, developers ship product — not tickets.
A unified interface for discovering services, spinning up environments, viewing documentation, and monitoring deployments. Self-service — no ticket required.
Clerk, WorkOS, and Auth0 offer beautiful, developer-friendly auth UIs — as cloud services. AravaliStack ships the same experience entirely on-prem. Your Keycloak instance powers embeddable sign-in, sign-up, organisation management, and billing components that developers drop into their applications in minutes.
Browser-based development environments running inside your infrastructure. No "it works on my machine." Environments defined as code, versioned alongside application code.
Automated testing — load testing, end-to-end testing, performance benchmarking — integrated into the deployment pipeline. Every deployment passes the same quality gates.
Per-team cost attribution, budget enforcement, and idle workload detection — built into the platform. Answer the CFO's question before it's asked.
Most enterprises can't tell you — with confidence — what last month's infrastructure cost, broken down by team, project, or product line. AravaliStack solves this as a first principle.
Every resource in AravaliStack is tagged, attributed, and reported — automatically. Cost is not a finance team problem. It is a platform feature.
AravaliStack's cost layer exposes a Lago-compatible REST API — the leading open-source billing standard. Connect any finance system (Tally, SAP, Zoho Books, Stripe) to pull tenant usage data, trigger invoices, and reconcile actuals against budgets.
When engineers can see the cost of what they're deploying — in real time — they make different decisions. Not because they're forced to, but because they have the information.
AravaliStack puts cost context where engineering decisions are made: in the deployment pipeline.
AravaliStack is an enterprise-grade, on-premise Platform as a Service (PaaS) developed and commercialised by TechRajendra® (Rajendra Management Pvt. Ltd.) — operating as TechRajendra® — a technology company registered in New Delhi, India, with 9+ years of enterprise infrastructure expertise. AravaliStack enables Indian enterprises, government bodies, and regulated industries to achieve public-cloud capabilities — comparable to hyperscalers — directly on their own infrastructure, while retaining complete control over data, compliance, and governance. In addition to fully on-premise deployments, AravaliStack integrates seamlessly with AWS and GCP, enabling hybrid and multi-cloud architectures from a unified control plane. The founding conviction: enterprises that control their infrastructure are more secure, more cost-efficient, and more resilient than those that rent it.
The Aravali mountain range is the oldest in India — over a billion years old. It has shaped the geography, climate, and civilisation of the subcontinent. It doesn't move. It doesn't negotiate. It endures.
We named our platform after the Aravali because we believe infrastructure should work the same way. Not trendy. Not temporary. Not dependent on conditions outside your control. Permanent. Layered. Yours.
The hexagon in our logo echoes the geometry of the mountain ridge. The stack in our name reflects our conviction that a platform must be complete — every component connected, every boundary trusted.
"Every enterprise deserves to own its infrastructure completely. Not rent it. Not depend on it. Own it — the way the Aravali mountains own the landscape."
Rajendra Management Pvt. Ltd. operates two complementary technology businesses. TechRajendra.com is the IT consulting and solutions arm — 9+ years of experience delivering custom software, ERP, HRMS, CRM, BaaS, and enterprise mobility to businesses across India, with technology partnerships spanning Intel, Dell, AWS, Cisco, Microsoft, IBM, SAP, Red Hat, NVIDIA, VMware, and Odoo.
AravaliStack is the sovereign cloud platform product that emerged from Rajendra Management's decade of enterprise infrastructure engagements. Every architecture decision in AravaliStack reflects hard-won knowledge from deploying and running infrastructure for banks, hospitals, and government bodies.
When you deploy AravaliStack, you get not just a platform — you get the institutional knowledge of TechRajendra® that has built, broken, and rebuilt enterprise infrastructure across every regulated sector in India.
Through TechRajendra, Rajendra Management holds certified partnerships with the technology companies whose products power enterprise infrastructure globally — the same ecosystem that underpins AravaliStack's hardware and software recommendations.
We're hiring engineers who care deeply about getting infrastructure right.
AravaliStack is a small, disciplined team building something that genuinely matters. If you care deeply about infrastructure, security, and getting things right — we'd like to talk.
We hire the right people ahead of the right job description. If you're exceptional at infrastructure, security, or ML systems — write to us.
Choose what brings you here. Each path connects you to the right person at AravaliStack immediately.
Every demo is run by a platform engineer. No slides, no scripts.
A real conversation about your infrastructure, not a product tour.
AravaliStack is built for regulated environments. This page documents our security posture, certifications, and how we respond to vulnerabilities.
We operate a responsible disclosure programme. If you find a security vulnerability in AravaliStack, we want to hear from you — and we commit to acknowledging your report within 48 hours.
Talk to our security team — not a questionnaire portal.
Architecture thinking, engineering decisions, and hard-won lessons from building India's sovereign cloud platform — written by the people building it.
New articles when they're ready — no schedule, no filler.
Every vendor selling a firewall, an endpoint tool, or a SIEM product calls it "zero trust" now. The term has been so thoroughly weaponised by marketing departments that it has become nearly meaningless. Which is a shame, because the actual architectural principle behind zero trust is one of the most important ideas in enterprise security of the last decade.
This article is not a product review. It is an attempt to explain what zero trust actually requires — at an architectural level — and why implementing it correctly is hard enough that most organisations claiming to have done it have not.
The original formulation, from the Forrester research of the early 2010s and Google's BeyondCorp paper from 2014, is this: assume breach. Design your system as if the attacker is already inside your network. Perimeter security — the idea that everything inside the firewall is trusted — is insufficient because the perimeter is always eventually breached.
Zero trust replaces perimeter trust with three principles applied universally:
That's it. That is zero trust. Everything else is an implementation decision.
The most common failure mode is what we call perimeter replacement: organisations buy a zero trust network access (ZTNA) product, route their user traffic through it, declare victory, and move on. What they've done is replaced one perimeter (the firewall) with another (the ZTNA gateway). The service-to-service traffic inside the cluster still trusts everything. The database connections still use static credentials. The CI/CD pipeline still has root on the cluster.
None of that is zero trust. That is a VPN with better marketing.
There are four layers where zero trust must be implemented before a system can honestly claim the property:
Human identity is the easy part — most organisations have an IdP (Keycloak, Okta, Azure AD) that handles SSO and MFA. The hard part is machine identity. In a typical Kubernetes cluster, services authenticate to each other using one of three mechanisms, in order of how common they are: static API keys in environment variables, shared service account tokens, or nothing at all (the network is trusted).
All three of these are wrong. The correct answer is SPIFFE (Secure Production Identity Framework for Everyone) — a standard for issuing cryptographically verifiable identities to workloads. Under SPIFFE, every pod, every service, every agent gets an SVID (SPIFFE Verifiable Identity Document) — a short-lived X.509 certificate that identifies it to any other service it calls. No static credentials. No shared secrets. The identity is the certificate, and the certificate expires in hours, not years.
Authentication answers "who are you?" Policy answers "what are you allowed to do?" These are different problems, and conflating them is one of the most common architectural mistakes.
In AravaliStack, we use Open Policy Agent (OPA) for policy enforcement. Every API call — whether it originates from a human, a service, or an AI agent — passes through an OPA policy check before it executes. The policy is declared in Rego, version-controlled in Git, and reviewed in pull requests before deployment. Policy changes have exactly the same review process as code changes.
The critical property is separation: the policy engine is independent of both the identity provider and the services being protected. This means you can change policy without redeploying services, audit policy independently of application code, and enforce consistent access decisions across heterogeneous services.
This sounds obvious in 2026. It is still not universally implemented. In most production Kubernetes clusters, pod-to-pod traffic is unencrypted. The reasoning is usually "it's inside the cluster, so it's safe." This is exactly the perimeter thinking that zero trust is meant to replace.
The correct implementation is mutual TLS (mTLS) for all service-to-service communication. Every connection is encrypted. Every connection is authenticated in both directions — the client verifies the server's identity and the server verifies the client's. In AravaliStack, this is enforced at the service mesh layer (Istio) — services cannot opt out of mTLS because the mesh enforces it at the sidecar proxy level, not at the application level.
The final layer is secrets management. A system that has verified identities, enforced policies, and encrypted all traffic still fails zero trust if its database passwords are static strings in Kubernetes Secrets (which are base64-encoded, not encrypted, by default).
Zero trust secrets management means:
Here is the flow for a typical service call in an AravaliStack deployment — a payment processing service calling a transaction history API:
At no point does any service trust another service because of network position. At no point does any static credential exist that, if leaked, would provide persistent access. At no point does a policy change require a deployment.
Most systems that claim to be zero trust are not. They have an SSO provider and a ZTNA product, and they have done nothing about service-to-service authentication, policy-as-code, mTLS enforcement, or dynamic secrets. These are the hard parts, and they require architectural commitment — not procurement.
Zero trust is not a product. It is the property that emerges when you implement authentication, authorisation, encryption, and secrets management correctly — across every layer, for every identity, on every request. It is genuinely hard to do. It is worth doing. And the fact that a vendor's product claims to deliver it in a checkbox does not make it so.
In the early days of building AravaliStack, we made a decision that seemed radical to some of our early users: every piece of platform state — infrastructure, application deployments, cost budgets, ML training jobs, network policy — must be declared in Git. No exceptions. No kubectl exec in production. No clicking through a dashboard to change a replica count. Git is the only control plane.
Eighteen months and several hundred production deployments later, we haven't regretted it once.
Before GitOps, the typical enterprise Kubernetes workflow looks like this: developers write YAML, apply it to a cluster with kubectl, tweak things when they break, sometimes write down what they did, often don't. The cluster accumulates state that nobody fully understands. "Works on my machine" becomes "works on our cluster" — until it doesn't, and nobody can reproduce the state that was working.
For regulated industries, this is worse than an inconvenience. When an RBI auditor asks "show me the configuration of your payment processing service as it was on 14 February 2026," the answer in a traditional workflow is: "we'll check the cluster, but we might have made some changes since then." That is not an acceptable answer.
GitOps means two things: declarative state, and automated reconciliation.
Declarative state means every resource in your platform — Kubernetes deployments, HPA configurations, network policies, Vault secret paths, cost budget limits, ML training job specs — is defined as a file in a Git repository. When you want to change something, you change the file and commit. The Git history is the complete history of your infrastructure.
Automated reconciliation means a controller (Flux CD or ArgoCD) continuously compares the desired state in Git against the actual state in the cluster. Any drift — whether caused by a failed deployment, a manual kubectl change, or a node failure — is detected and automatically corrected. The cluster always converges back to what Git says it should be.
Every change to every piece of platform state has a Git commit hash, an author, a timestamp, a commit message, and (if you use pull requests) a review trail. When a regulator asks what your production configuration looked like on a specific date, you git checkout that commit and show them. No reconstruction. No "we think it was..."
When you lose a cluster — hardware failure, accidental deletion, catastrophic upgrade — recovery is deterministic. You point Flux at the Git repository and it rebuilds the entire cluster to the last committed state. We have run this drill multiple times. In a well-structured GitOps setup, full cluster recovery from scratch takes under 45 minutes.
In most enterprises, change management is a separate process — JIRA tickets, CAB approvals, email chains. In a GitOps workflow, the pull request IS the change management process. The description explains why, the diff shows exactly what changes, the review trail shows who approved, and the merge commit records when it went to production. No separate tool required.
Most teams use GitOps for application deployments. We extended it further:
"What about hotfixes? Sometimes you need to change something in production right now."
Our answer: yes, and you still use Git. The process is faster — you skip the full review cycle, you get one senior engineer to approve, you merge — but you still use Git. The reason is not bureaucracy. The reason is that a hotfix applied directly to the cluster will be undone by Flux the next time it reconciles, which creates exactly the category of incident you were trying to avoid. Git is not slow. Unreviewed PRs can merge in under 5 minutes when urgency requires it.
We chose GitOps as the only control plane not because we wanted to add process, but because we wanted to eliminate the class of incidents that comes from undocumented, unreviewable, unrepeatable changes to production state. Eighteen months in, that class of incident has not occurred once.
Imagine a bank that has spent fifteen years collecting transaction data on 40 million customers. Every fraud pattern, every credit risk signal, every behavioural anomaly that their models detect is embedded in that data. It is, without exaggeration, their most valuable asset after their deposit base.
Now imagine that the fraud detection model that analyses this data runs on a third-party cloud provider's GPU cluster, in a data centre outside India. The raw transaction data — names, amounts, merchant categories, geolocation signals — is transmitted to that cluster for inference, and the results are returned.
This is a common arrangement. Most of the organisations we talk to have something close to this. When we ask their CISOs whether they've assessed the risk, the answer is usually a variant of: "We know it's a problem. We haven't found a workable alternative."
This article is about the workable alternative.
The RBI's Master Direction on Information Technology Governance (2023) and the DPDP Act both require that personal data of Indian residents be processed within India, and that critical financial data not be transferred to foreign jurisdictions without specific conditions being met. Sending transaction-level customer data to a US or EU cloud provider for ML inference may — depending on how your DPA reads it — constitute a cross-border data transfer that requires regulatory approval you do not have.
SEBI's cloud framework for market infrastructure institutions is similarly explicit: data classification requirements effectively prohibit sensitive market data from leaving controlled environments.
This one is less discussed but arguably more immediately impactful. Your ML models are trained on proprietary data and encode proprietary signals. The model weights themselves represent years of competitive learning. When those models run on shared cloud infrastructure, you are operating in an environment where — regardless of contractual commitments — your model's behaviour, inputs, and outputs are accessible to the cloud provider's infrastructure at the hardware layer.
For organisations whose entire competitive moat is their data and their models — every NBFC, every insurance underwriter, every algorithmic trading firm — this is not a theoretical concern.
In March 2024, a major cloud provider experienced a regional outage that lasted 7 hours. For organisations running their fraud detection, credit decisioning, and KYC models on that provider's infrastructure, the operational impact was not "slow website." It was suspended customer onboarding, paused credit decisions, and degraded fraud detection across millions of active sessions.
The reason most organisations don't self-host ML is not that they've evaluated it and found it lacking. It is that the perceived complexity is high, and the cloud alternative is immediately available. Let's actually enumerate what you need:
Modern inference workloads for mid-size models (7B–13B parameters) run well on NVIDIA L40S or A100 GPUs. A 4-GPU server handles most enterprise inference loads with headroom. The economics are straightforward: at the usage levels of a large bank's fraud detection system, owned hardware pays for itself in under 18 months versus cloud GPU pricing. For training workloads, the math is even more favourable.
KServe (formerly KFServing) on Kubernetes handles model deployment, versioning, A/B testing, canary rollouts, and auto-scaling on GPU utilisation. This is the infrastructure equivalent of what Replicate or Hugging Face Inference API provides — except pointed at your own GPUs, with your data never leaving your network. The API surface is identical. The developer experience is identical. The data residency is completely different.
MLflow handles experiment tracking — every training run has a logged set of hyperparameters, metrics, data hashes, and model artifacts. When your model produces an anomalous output and your regulator asks "what version of the model was running and what was it trained on," MLflow gives you a complete, traceable answer. This matters more than most teams realise until they need it.
Production ML systems fail in ways that are different from traditional software. Models drift. Their accuracy degrades gradually. Inputs change distribution. You need monitoring that is specifically aware of ML semantics — not just "is the service up" but "is the model's output distribution consistent with its training distribution." This requires prompt tracing (for LLMs), feature drift detection (for traditional ML), and token cost attribution (to understand operational costs).
A common question: "What about open-source models like LLaMA, Mistral, or Gemma? Can we just use those on our own hardware?"
Yes. Completely. This is, in many ways, the most important development in enterprise ML of the last two years. Models that are functionally competitive with GPT-4-class capability for many enterprise tasks — document classification, entity extraction, summarisation, code generation — are now available under open licences, deployable on modest hardware, with no API call leaving your network.
A bank deploying Mistral-7B for document summarisation on a 2-GPU server processes thousands of loan application documents per day, with zero data egress, at a marginal cost that is essentially electricity. The alternative — GPT-4 API calls — is faster to implement, but carries every risk we've described above.
For organisations starting from scratch, the sequence that works:
The organisations that will have a structural ML advantage in five years are not the ones that trained the biggest models. They are the ones that built the infrastructure to run any model they choose, on their own hardware, with their proprietary data, in an auditable and regulatorily compliant way.
The word "multi-tenancy" gets used to mean a lot of different things. At the minimal end, it means "multiple teams share a Kubernetes cluster." At the full end, it means "multiple organisations with legally separate data and compliance requirements operate on the same physical infrastructure, with cryptographic guarantees that their workloads cannot interact." The gap between those two definitions is enormous — and most platforms that claim multi-tenancy are firmly at the minimal end.
This article describes what real multi-tenancy requires, why it matters, and how AravaliStack implements it from the network layer up to the billing dashboard.
The most common multi-tenancy pattern in Kubernetes is namespace isolation: each team or tenant gets a namespace, RBAC rules prevent them from accessing each other's resources, and a ResourceQuota limits how much compute they can consume. This is a reasonable starting point. It is not sufficient for regulated environments.
Here's why: Kubernetes namespaces are a logical construct. The network is shared. By default, any pod in any namespace can send a TCP packet to any other pod in any other namespace. The application isn't supposed to — but the network doesn't prevent it. For a hospital system where Tenant A is a cardiology department and Tenant B is an oncology department, "the application isn't supposed to" is not an acceptable isolation guarantee.
AravaliStack enforces network isolation using Kubernetes NetworkPolicy (enforced by Calico or Cilium). Every namespace has a default-deny policy applied at creation: no ingress or egress is permitted unless explicitly allowed. Tenants must declare every network dependency — which services they call and which services can call them — and those declarations are reviewed before being applied.
For the highest-sensitivity deployments (defence, classified environments), we extend this to VLAN segmentation at the physical network layer — namespace-to-VLAN mapping, enforced by the CNI plugin. Traffic between classification levels requires explicit cross-domain guard configuration.
Shared node pools are fine for most tenants. For tenants that require hardware-level isolation — either for security (confidential compute) or performance (guaranteed GPU allocation) — AravaliStack supports dedicated node pools with Kubernetes taints and tolerations. A tenant's workloads only run on nodes labelled for them; other pods are rejected by the scheduler.
Every tenant gets separate Persistent Volumes provisioned from separate storage classes. The storage class for a regulated-data tenant uses encryption-at-rest with a tenant-specific encryption key, managed by Vault. Tenant A's data cannot be read by Tenant B even with direct storage access — the keys are different, and both are managed by Vault with per-tenant access policies.
Keycloak is configured with a realm per tenant (or per tenant group, depending on isolation requirements). Each realm has its own users, groups, roles, and SSO configuration. A user authenticated in Tenant A's realm has no identity in Tenant B's realm — the identity providers are completely separate. Ory Keto's permission system enforces that resources owned by Tenant A cannot be accessed by Tenant B's identities, regardless of what permissions they claim.
Vault uses a namespace-per-tenant model (Vault Enterprise) or separate secret mount paths per tenant. A service in Tenant A's namespace can only request secrets under the Tenant A path in Vault. The Vault policy that governs this is managed through GitOps and is audited at every change.
Here is the layer that most multi-tenant platforms omit entirely: billing. If tenants share infrastructure, who pays for what? In most enterprise Kubernetes deployments, the answer is "it comes out of a shared IT budget and nobody knows the breakdown." This causes two problems.
The first is financial: teams that over-consume pay nothing extra, which eliminates any incentive for cost-efficient engineering. The second is audit: for MSPs deploying AravaliStack for external clients, the inability to produce accurate per-tenant usage invoices is a business-critical problem.
AravaliStack's cost layer uses OpenCost for per-namespace resource attribution — every CPU-hour, every GB-hour of storage, every GB of network egress is measured and attributed to the namespace it was consumed in. This data is available in real-time through the cost dashboard and through the Lago-compatible billing API. MSPs can generate per-tenant invoices directly from the platform's usage data.
Multi-tenancy is not just technical isolation — it is also governance isolation. Tenant A's platform administrator should not be able to modify Tenant B's namespace policies. The platform operator (the MSP or central IT team) should be able to see everything but modify only platform-level configuration, not tenant-level application state.
AravaliStack implements this through a three-level RBAC hierarchy:
These roles are defined in Git, applied by Flux, and audited in Vault's access log. No role escalation is possible without a Git PR and a platform operator approval.
Multi-tenancy done right is hard. It requires decisions at seven different layers of the stack, each of which adds complexity that must be managed. But for the class of enterprises AravaliStack serves — regulated, multi-team, often multi-client — the alternative is either a separate cluster per tenant (which is operationally untenable at scale) or inadequate isolation (which is a compliance liability). The architecture we've described is the third path.
Most organisations treat infrastructure cost as a finance problem. The monthly cloud bill arrives, finance investigates, engineering gets a memo asking for "cost optimisation," and for two weeks everyone is conscious of their resource usage. Then the cycle repeats.
This approach has a fundamental flaw: the people who receive the bill (finance) are not the people who made the decisions that created the bill (engineers). And the people who made the decisions made them weeks or months ago, in a context they no longer remember, without any visibility into the cost implications at the time.
The fix is conceptually simple: put cost information where engineering decisions are made. For modern software teams, that means the CI/CD pipeline.
When an engineer opens a pull request that changes a Kubernetes deployment manifest — increasing replica count, upgrading to a larger instance type, adding a new sidecar container — they are making a cost decision. They almost certainly don't think of it that way. They're solving an application problem.
Now imagine that the CI pipeline runs a cost estimate and posts a comment on the PR:
The engineer now has the information they need to make a decision. They can ask: is the performance improvement worth twice the cost? Can I achieve the same result with 4 replicas instead of 6? Should I talk to my team lead before merging this?
None of this stops the engineer from merging the change. It gives them information. That is the entire intervention — information, at the moment when it is useful.
Within weeks of deploying cost estimates in pull requests, we consistently see the same pattern in our customer deployments: engineers start designing around cost efficiency without being asked. They choose smaller instance types when they can. They set appropriate resource requests. They ask whether they actually need the replica count they were about to set. This is not because they're being forced to — it's because they now have the context to make informed tradeoffs.
Cost reviews stop being "why was last month's bill so high?" and start being "this planned change to the payments service will cost an extra ₹18,400/month — do we approve it?" Finance and engineering are now having the same conversation, about the same decision, at the same time. The budget review cadence doesn't have to change; the quality of the conversation changes entirely.
A misconfigured deployment that consumes 10x expected resources will appear as a large cost delta in the CI pipeline at deployment time. In the traditional model, it appears as a line item in the monthly bill three to four weeks later, by which time it has been running at 10x cost for the entire period. Early detection is not a marginal improvement. It is the difference between a ₹50,000 anomaly and a ₹15,00,000 one.
AravaliStack implements this through a combination of OpenCost (for resource pricing data), Kubernetes resource request parsing (from the manifest diff), and a pipeline plugin that calculates the delta and posts the comment.
The key implementation decisions:
As LLM-based features become part of enterprise applications, the same principle extends to AI inference costs. An engineer adding a "summarise this document" feature backed by an LLM inference call should see, in their PR, an estimate of the token cost at the expected usage volume.
This is increasingly important: at scale, LLM inference costs can easily exceed compute infrastructure costs. An enterprise application making 500,000 LLM API calls per day at ₹0.15 per call is spending ₹75,000 per day on inference alone — a cost that is completely invisible in the traditional model until it appears on the bill.
Infrastructure cost is an engineering problem that has been delegated to finance for decades. The right fix is not better financial reporting — it is better engineering feedback loops. The CI/CD pipeline is where engineers spend their time. That is where cost information belongs.
There is a moment in every naming process for a technical product where someone suggests something that sounds like a cloud provider — something with "flow," "stream," "scale," or "ops" in it. We went through that phase. We rejected all of it.
We wanted a name that meant something. Something that said what we believe about infrastructure without requiring a two-paragraph explanation. The Aravali range was the answer, and once we found it, it was obvious.
The Aravali Hills are the oldest mountain range in the Indian subcontinent — geologically, among the oldest surviving mountain ranges on earth, formed roughly 1.5 to 2 billion years ago during the Proterozoic era. They run 800 kilometres from Gujarat through Rajasthan into Haryana and Delhi, right through the heart of the subcontinent.
They are not dramatic mountains. They are not the Himalayas — tall, young, geologically active, still growing. The Aravali are old, weathered, low to the ground. They have been there for so long that the rivers of northern India have shaped themselves around them. The cities of the region — Delhi, Jaipur, Ajmer, Udaipur — have grown in their shadow. The range has shaped the climate, the ecology, and the civilisation of the subcontinent in ways that are so foundational they are invisible.
That invisibility is the point.
When we named AravaliStack, we were making a claim about what infrastructure should be. Not trendy. Not impressive on a conference slide. Not dependent on the business model of a vendor in another country. Permanent. Reliable. Yours.
The Aravali doesn't depend on anyone. It doesn't need a subscription. It doesn't send you an invoice for egress. It has been doing its job — shaping the watershed, breaking the desert winds, supporting the ecosystem — for longer than human civilisation has existed. It will still be doing it long after we're gone.
We think enterprise infrastructure should work the same way. It should be something your organisation owns so completely that it becomes invisible — a foundation you build on, not a dependency you manage.
The second word is just as deliberate. We chose "Stack" over "Cloud," "Platform," "Base," or any of a dozen alternatives because a stack implies something specific: layers that are connected, integrated, and mutually dependent. Each layer in a stack sits on the layer below it. Change the bottom and everything above it is affected. Get the foundations right, and the rest follows.
AravaliStack is built layer by layer — compute, then networking, then security, then data, then ML, then developer experience, then cost. We did not add a layer until the layer beneath it was production-documented, operationally tested, and genuinely reliable. The stack metaphor is not marketing. It is how we actually built it.
There is a third thing the name does: it locates us. The Aravali range is in India. Its mention — at least for anyone who grew up in northern India — carries an immediate sense of place. Delhi's skyline on a clear day shows the hills in the distance. The geology of the national capital sits on Aravali bedrock.
We are an Indian company building infrastructure for Indian enterprises. The regulatory environment we serve — RBI, SEBI, DPDP, CERT-IN, NCIIPC — is Indian. The enterprises we work with — banks in Mumbai, hospitals in Delhi, government agencies across the country, defence installations in sensitive locations — are Indian. The conviction that Indian enterprises should control their own digital infrastructure is a conviction rooted in India's specific history with sovereignty and self-reliance.
Naming the platform after an Indian geological landmark is not nationalism. It is honesty about where we are, who we serve, and what we believe.
The hexagon in our logo is a direct reference to the cross-section of the Aravali ridge — the geometric pattern that emerges when you cut through the rock formations. It is also a reference to the honeycomb structure that appears in nature wherever something needs to be simultaneously strong and efficient. And it echoes the hex grid that appears in many computing contexts.
We like that it works on all three levels at once. The best design decisions usually do.
Names set expectations. When you call something "Aravali," you are invoking permanence, reliability, depth. You are making a promise that the thing you built will be there, will hold, will not surprise you with instability or impermanence.
That is a high bar. We are aware of it. It is why we do not release a layer until it is genuinely production-ready. It is why we write operational runbooks before we ship features. It is why we take compliance documentation as seriously as the code itself. The name is not a brand decision. It is a standard we hold ourselves to.
The Aravali has been standing for 1.5 billion years. We have been building for three. But the aspiration is the same: infrastructure so reliable that you stop thinking about it, and start building on top of it.
Real organisations. Real infrastructure challenges. Real outcomes from choosing sovereignty over dependency.
AravaliStack is priced on the basis that your infrastructure bill should never surprise you. Fixed, capacity-based pricing — agreed upfront, nothing variable.
All plans include zero-trust enforcement, GitOps-native control, and full platform access. No feature gatekeeping.
AravaliStack is deployed into your infrastructure. The right configuration depends on your existing environment, scale, compliance requirements, and team structure. A 30-minute conversation results in a precise, itemised proposal.
What appears on the proposal appears on the invoice. Nothing added later.
No commitment. A direct conversation with an engineer.
Real-time status of AravaliStack platform components. Subscribe to incident notifications below.
Get notified by email the moment an incident is detected or resolved.
We don't compete on price. We compete on ownership, auditability, and the fact that your data never leaves your control.
Public cloud is flexible and fast. But for regulated Indian enterprises, the math changes when you factor in data residency, audit liability, and egress costs.
"We'll just set up Kubernetes ourselves" — we hear this often. Here's what that actually costs.
Managed K8s gives you orchestration. AravaliStack gives you a complete enterprise platform — security, developer experience, ML, cost, and compliance all integrated.
We'll prepare a customised comparison using your actual infrastructure footprint and compliance requirements.
Most organisations undercount their true cloud cost by 40–60%. This calculator surfaces the full picture — compute, egress, compliance overhead, and engineering time.
All estimates are conservative. Speak with our solutions team for exact numbers.
We've migrated enterprises from every major public cloud and on-premise setup. These guides distil what we've learned into repeatable, low-risk migration paths.
ECS/EKS to AravaliStack Kubernetes. S3 to MinIO. IAM to Vault + Keycloak. Route 53 to self-hosted DNS. Step-by-step with rollback plans for each phase.
GKE to AravaliStack. Cloud Storage to MinIO. BigQuery workloads to self-hosted Spark + Trino. Vertex AI to self-hosted ML stack. Full data pipeline migration.
AKS to AravaliStack. Azure AD federation to Keycloak. Blob Storage to MinIO. Azure Monitor to Prometheus + Grafana. DevOps pipelines to ArgoCD.
Starting from physical servers with no orchestration — manual deployments, shadow IT, no cost visibility. AravaliStack brings order without replacing hardware.
We always run parallel — new platform alongside old. No big-bang cutovers. Rollback is always possible at every phase.
Audit trails, access controls, and compliance mappings are verified before any workload moves. Your auditors can review at every step.
We transfer knowledge throughout the migration. By go-live, your engineers operate and extend the platform independently.
System integrators, cloud advisors, and technology vendors — AravaliStack's partner programme gives you technical enablement, deal registration, and co-marketing support to grow your enterprise cloud practice.
Deploy and manage AravaliStack for your enterprise clients. Access to technical training, certified deployment methodology, deal registration, and margin protection.
Integrate your product with AravaliStack. Listed in our integration ecosystem, access to sandbox environments, joint solution briefs, and co-sell opportunities.
Cloud consultants, independent advisors, and architects who recommend AravaliStack. Earn referral fees on closed deals with zero ongoing obligations.
Our partnership team will assess your practice and recommend the right starting point.
Everything you need to write accurately about AravaliStack — brand assets, factsheet, executive bios, and press contact.
We respond to press enquiries within 24 hours on business days. For urgent requests, please indicate in your subject line.
"AravaliStack brings enterprise-grade sovereign cloud capability to Indian organisations for the first time without the complexity of DIY infrastructure."
Read article →"The platform that's making Indian enterprises rethink their cloud strategy — and reclaim ownership of their data."
Read article →"India's data sovereignty conversation is getting infrastructure. AravaliStack is building the plumbing for Indian enterprise independence."
Read article →AravaliStack provides contractual SLAs across all platform components. Here's exactly what you can expect — and what happens if we don't deliver.
Mission-critical environments have unique needs. We'll craft an SLA that meets your board's and auditor's requirements.
All governing documents for your use of AravaliStack products and services. Effective: 1 March 2026.
How we collect, use, store, and protect personal data. DPDP Act compliant. Effective 1 March 2026.
The binding agreement governing access to and use of AravaliStack software and services. Effective 1 March 2026.
Effective Date: 1 March 2026 | Last Revised: 1 March 2026
This Privacy Policy ("Policy") is issued by Rajendra Management Pvt. Ltd., a company incorporated under the Companies Act, 2013, with its registered office at Plot No. 190, 3rd Floor, Pocket A2, Sector 17, Golf Course Road, Dwarka, New Delhi – 110075, India, operating the AravaliStack platform and the TechRajendra® brand (collectively, "Company," "we," "us," or "our").
This Policy applies to all personal data processed by the Company in connection with: (a) use of the AravaliStack software platform and associated services ("Platform"); (b) access to or use of our websites at www.aravalistack.com and www.techrajendra.com; (c) any commercial, contractual, or pre-sales engagement with the Company; and (d) communications directed to or received from the Company by any means.
This Policy is consistent with and governed by the Digital Personal Data Protection Act, 2023 ("DPDP Act"), the Information Technology Act, 2000, the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, and, to the extent applicable to data subjects located in the European Economic Area or United Kingdom, the General Data Protection Regulation (EU) 2016/679.
For purposes of the DPDP Act, 2023, the Company is the Data Fiduciary in respect of personal data collected through the Platform and our websites. Where the Platform is deployed by an enterprise customer on their own infrastructure (on-premise deployment), the enterprise customer is the Data Fiduciary in respect of their end-users' personal data, and the Company acts solely as a Data Processor to the extent of any data shared with us for support, maintenance, or monitoring purposes.
The Company has designated a Grievance Officer in accordance with the IT Act and DPDP Act. Contact: [email protected] · Rajendra Management Pvt. Ltd., Plot No. 190, Dwarka, New Delhi – 110075.
We collect personal data only to the extent necessary for the purposes set out in this Policy. The categories we may collect include:
Full name, job title, employer name, and professional contact information provided during registration, demo requests, procurement enquiries, or contractual engagement.
Business email address, office telephone number, and mailing address. We do not collect personal mobile numbers unless voluntarily provided for support purposes.
IP address, browser type and version, device identifiers, access timestamps, referring URL, and pages visited on our websites. Collected automatically via server logs and, where consented, analytics tools.
Platform feature usage telemetry, API call patterns, and configuration metadata — collected only in respect of Platform licensees and only where the enterprise customer's agreement permits such telemetry for support and product improvement purposes.
Contents of emails, support tickets, and form submissions directed to us. Retained for the period necessary to resolve the subject matter and for a further period of three (3) years for legal and compliance purposes.
We do not collect sensitive personal data as defined under the SPDI Rules (including financial information, health records, biometric data, or sexual orientation) in the ordinary course of business. If such data is shared with us inadvertently, we will notify you and delete it promptly.
We process personal data only where we have a lawful basis to do so. The purposes and corresponding legal bases are as follows:
| Purpose | Legal Basis (DPDP Act) |
|---|---|
| Responding to enquiries and demo requests | Consent / Legitimate use |
| Performing and administering contracts with enterprise customers | Performance of contract |
| Providing technical support and maintenance | Performance of contract / Legitimate use |
| Sending product updates and security advisories | Legitimate use (existing customers) / Consent (prospects) |
| Security monitoring and fraud prevention | Legal obligation / Legitimate use |
| Compliance with applicable law and regulatory obligations | Legal obligation |
AravaliStack is architected as a sovereign, on-premise platform. Personal data of Indian residents processed through customer-deployed instances of AravaliStack remains within the customer's own infrastructure and is not transferred to or stored on Company servers unless the customer initiates a support engagement that requires diagnostic data sharing.
In respect of personal data held by the Company (such as contact details of enterprise customers' representatives), such data is stored on servers located in India. Any cross-border transfer of personal data is conducted only: (a) with the explicit consent of the data principal; (b) pursuant to a contractual necessity; or (c) in compliance with rules notified by the Central Government under Section 16 of the DPDP Act.
We will update this Policy promptly upon notification of any cross-border transfer restrictions issued under the DPDP Act.
We retain personal data only for as long as is necessary to fulfil the purpose for which it was collected, or as required by applicable law. Our standard retention periods are:
Upon expiry of the applicable retention period, personal data is securely deleted or anonymised in a manner that prevents re-identification.
Subject to the provisions of the DPDP Act and applicable regulations, you have the following rights in respect of your personal data held by us:
Obtain a summary of the personal data held about you and the processing activities undertaken.
Request correction of inaccurate or incomplete personal data.
Request deletion of personal data where processing is no longer necessary or where consent has been withdrawn, subject to legal retention requirements.
Lodge a complaint with our Grievance Officer. If unsatisfied, escalate to the Data Protection Board of India.
Nominate another individual to exercise these rights on your behalf in the event of your death or incapacity.
Withdraw consent at any time, without affecting the lawfulness of processing prior to withdrawal.
To exercise any right, write to [email protected]. We will respond within 30 days of receiving your request and, where required, within the timelines prescribed by the DPDP Act.
Our websites use the following categories of cookies and similar technologies:
We do not use advertising or behavioural tracking cookies. AravaliStack products are ad-free. We do not sell, rent, or share personal data with advertising networks or data brokers.
We implement and maintain technical and organisational measures appropriate to the risk of processing, including: encryption of data in transit (TLS 1.3) and at rest (AES-256); access controls on a least-privilege basis; regular vulnerability assessments; and incident response procedures in accordance with CERT-In reporting timelines. A summary of our security posture is available at our Security Trust Centre.
We may update this Policy from time to time to reflect changes in law, regulatory guidance, or our processing practices. The revised Policy will be published on this page with an updated effective date. Where the change is material, we will notify active customers by email at least 14 days before the change takes effect. Continued use of the Platform or our websites after the effective date constitutes acceptance of the revised Policy.
This Policy is governed by the laws of India. Any dispute arising out of or relating to this Policy that is not resolved through our grievance mechanism shall be subject to the exclusive jurisdiction of the courts at New Delhi, India.
Questions about this Policy?
Effective Date: 1 March 2026 | Last Revised: 1 March 2026
"Agreement" means these Terms of Service together with any applicable Order Form, Statement of Work, or Schedule executed between the parties.
"AravaliStack" or "Platform" means the enterprise on-premise Platform as a Service software, including all modules, updates, patches, documentation, and APIs made available by the Company under this Agreement.
"Company" means Rajendra Management Pvt. Ltd. (operating as TechRajendra®), its successors, and permitted assigns.
"Customer" means the enterprise entity that has executed an Order Form or accepted these Terms.
"Customer Data" means all data, workloads, and information processed by Customer using the Platform on Customer's own infrastructure.
"Documentation" means the technical, operational, and user documentation provided by the Company with respect to the Platform.
"Authorised Users" means the employees, contractors, or agents of Customer who are authorised by Customer to access and use the Platform under the Agreement.
"Subscription Term" means the period specified in the relevant Order Form during which Customer is licensed to access and use the Platform.
Subject to Customer's full compliance with this Agreement and timely payment of all applicable fees, the Company grants Customer a non-exclusive, non-transferable, non-sublicensable, revocable licence during the Subscription Term to: (a) install and operate the Platform on Customer's own approved infrastructure; (b) permit Authorised Users to access and use the Platform solely for Customer's internal business operations; and (c) use the Documentation for the purpose of operating the Platform.
The licence expressly excludes the right to: (i) sublicense, resell, or otherwise commercially exploit the Platform or any part thereof to third parties, except where Customer is a Managed Service Provider ("MSP") that has entered into a separate MSP Agreement with the Company; (ii) modify, adapt, translate, or create derivative works of the Platform software; (iii) reverse engineer, decompile, or disassemble the Platform except to the extent permitted by applicable law; or (iv) remove or obscure any proprietary notices.
Open-source components incorporated into the Platform are licensed under their respective open-source licences, which are listed in the Platform's NOTICE file and available upon written request.
Customer shall: (a) be responsible for all activities conducted by Authorised Users under Customer's credentials; (b) implement and maintain reasonable physical, technical, and administrative security controls to protect access to the Platform; (c) comply with all applicable laws and regulations in connection with its use of the Platform, including the DPDP Act, applicable sector-specific regulations (including RBI, SEBI, IRDAI guidelines where applicable), and export control laws; (d) promptly notify the Company of any known or suspected security breach affecting the Platform; and (e) use the Platform only for lawful purposes and not in any manner that could damage, disable, or impair the Platform.
Customer is solely responsible for the accuracy, legality, and adequacy of Customer Data, and for obtaining all consents and authorisations required to process such data through the Platform. The Company does not access, process, or view Customer Data in ordinary course. Any support engagement requiring access to Customer Data will be conducted under a separate data processing addendum.
Fees for the Platform are set out in the applicable Order Form. Unless otherwise agreed: (a) all fees are invoiced annually in advance in Indian Rupees; (b) payment is due within thirty (30) days of invoice date; (c) undisputed amounts not paid within the due date shall attract interest at the rate of 1.5% per month or the maximum rate permitted by law, whichever is lower; and (d) the Company reserves the right to suspend access to support services (but not to the installed Platform software) upon thirty (30) days' written notice of non-payment.
Subscriptions renew automatically for successive Subscription Terms equal in duration to the initial term unless either party provides written notice of non-renewal at least sixty (60) days prior to the expiry of the then-current Subscription Term. The Company reserves the right to adjust fees at renewal upon sixty (60) days' prior written notice.
All fees are exclusive of applicable taxes. Customer shall be responsible for all goods and services tax (GST), withholding tax, or other statutory deductions applicable under Indian law. If Customer is required to withhold any taxes, the gross amount payable shall be increased such that the Company receives the net amount equal to the agreed fee.
The Platform, including all software, algorithms, interfaces, documentation, and proprietary methods embodied therein, is and remains the exclusive intellectual property of the Company or its licensors. Nothing in this Agreement transfers any ownership interest in the Platform or the Company's intellectual property to Customer.
Customer retains all right, title, and interest in Customer Data. Customer grants the Company a limited, non-exclusive licence to access Customer Data solely to the extent necessary to provide support services as requested by Customer.
AravaliStack™, TechRajendra®, and related marks are registered or unregistered trademarks of Rajendra Management Pvt. Ltd. Customer shall not use these marks without prior written consent, except to the extent necessary to accurately identify the Platform in ordinary business communications.
Each party ("Receiving Party") agrees to: (a) hold in strict confidence all Confidential Information of the other party ("Disclosing Party"); (b) use Confidential Information solely for the purposes of this Agreement; and (c) restrict disclosure of Confidential Information to those employees or contractors who need to know such information and who are bound by confidentiality obligations no less protective than those set out herein.
"Confidential Information" means all non-public information disclosed by either party that is designated as confidential or that reasonably should be understood to be confidential given its nature and the circumstances of disclosure, including the Platform's source code, architecture, pricing, and Customer Data. Confidentiality obligations survive termination of this Agreement for a period of five (5) years.
The Company warrants that: (a) it has the right and authority to grant the licence set out in Clause 2; (b) to its knowledge, the Platform does not infringe the intellectual property rights of any third party; and (c) the Platform will perform materially in accordance with the Documentation during the Subscription Term.
EXCEPT AS EXPRESSLY SET FORTH IN THIS CLAUSE, THE PLATFORM IS PROVIDED "AS IS." THE COMPANY EXPRESSLY DISCLAIMS ALL OTHER WARRANTIES, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT. THE COMPANY DOES NOT WARRANT THAT THE PLATFORM WILL BE UNINTERRUPTED OR ERROR-FREE.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW: (a) NEITHER PARTY SHALL BE LIABLE TO THE OTHER FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES, INCLUDING LOSS OF PROFITS, LOSS OF REVENUE, LOSS OF DATA, OR LOSS OF GOODWILL, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES; AND (b) THE COMPANY'S TOTAL CUMULATIVE LIABILITY ARISING OUT OF OR RELATED TO THIS AGREEMENT SHALL NOT EXCEED THE TOTAL FEES PAID BY CUSTOMER IN THE TWELVE (12) MONTHS IMMEDIATELY PRECEDING THE EVENT GIVING RISE TO THE CLAIM.
The limitations in this Clause shall not apply to: (i) death or personal injury caused by negligence; (ii) fraud or fraudulent misrepresentation; (iii) Customer's obligation to pay undisputed fees; or (iv) any liability that cannot be limited under applicable law.
By Company: The Company shall defend, indemnify, and hold harmless Customer against any third-party claim alleging that the Platform, as provided by the Company and used in accordance with this Agreement, infringes the intellectual property rights of such third party. This indemnity shall not apply where the claim arises from: (i) modifications to the Platform made by Customer; (ii) combination of the Platform with third-party products not approved by the Company; or (iii) use of the Platform in violation of this Agreement.
By Customer: Customer shall defend, indemnify, and hold harmless the Company against any third-party claim arising from: (i) Customer's breach of this Agreement; (ii) Customer Data, including any claim by a data principal in respect of processing of their personal data through the Platform; or (iii) Customer's use of the Platform in violation of applicable law.
This Agreement commences on the date of execution of the applicable Order Form and continues for the Subscription Term, unless terminated earlier in accordance with this Clause.
Termination for Cause: Either party may terminate this Agreement immediately upon written notice if the other party: (a) commits a material breach of this Agreement and fails to cure such breach within thirty (30) days of receiving written notice; or (b) becomes insolvent, makes an assignment for the benefit of creditors, or is subject to winding-up or insolvency proceedings that are not dismissed within sixty (60) days.
Effect of Termination: Upon termination or expiry, the licence granted herein shall immediately cease. Customer shall certify in writing, within thirty (30) days, that all copies of the Platform software have been destroyed or returned. Clauses 5 (Intellectual Property), 6 (Confidentiality), 7 (Warranties — Disclaimer section), 8 (Limitation of Liability), 9 (Indemnification), 11 (Governing Law), and any payment obligations accrued prior to termination shall survive.
This Agreement shall be governed by and construed in accordance with the laws of India, without regard to its conflict of laws provisions.
Escalation: The parties shall first attempt to resolve any dispute through good-faith negotiations at senior management level for a period of thirty (30) days from written notice of the dispute.
Arbitration: If the dispute is not resolved through negotiation, it shall be finally settled by binding arbitration under the Arbitration and Conciliation Act, 1996, as amended, by a sole arbitrator mutually agreed upon by the parties. The seat and venue of arbitration shall be New Delhi. The language of arbitration shall be English. The award shall be final and binding. Notwithstanding the foregoing, either party may seek emergency injunctive relief from the courts of New Delhi.
Entire Agreement: This Agreement, together with all Order Forms and Schedules, constitutes the entire agreement between the parties and supersedes all prior negotiations, representations, warranties, and understandings.
Amendment: No amendment to this Agreement shall be effective unless made in writing and signed by authorised representatives of both parties.
Assignment: Customer may not assign this Agreement or any rights hereunder without the prior written consent of the Company. The Company may assign this Agreement to any affiliate or in connection with a merger, acquisition, or sale of all or substantially all of its assets.
Severability: If any provision of this Agreement is held to be unenforceable, such provision shall be modified to the minimum extent necessary to make it enforceable, and the remaining provisions shall continue in full force and effect.
Force Majeure: Neither party shall be liable for any delay or failure to perform its obligations (other than payment obligations) to the extent caused by events beyond its reasonable control, including acts of God, natural disasters, pandemic, or governmental action.
Notices: All legal notices under this Agreement shall be in writing and delivered by registered post, courier, or email with read-receipt to the addresses specified in the Order Form. Notices to the Company shall be addressed to: Legal Department, Rajendra Management Pvt. Ltd., Plot No. 190, 3rd Floor, Pocket A2, Sector 17, Golf Course Road, Dwarka, New Delhi – 110075.
Questions about this Agreement?
Sign in to manage your deployment, view cost dashboards, and access support.
OT and IT convergence done properly. Real-time data from PLCs, SCADA systems, and sensors — processed at the edge, governed centrally, never leaving your plant perimeter.
Indian manufacturers are generating terabytes of operational data — from CNC machines, assembly lines, quality sensors, and logistics tracking. Most of it never gets used because moving it to public cloud is too expensive, and processing it on-site has been too complex.
AravaliStack brings enterprise-grade data infrastructure to the factory floor — edge compute, real-time streaming, and ML inference running inside your plant network, governed by the same zero-trust policies as your head office.
Network function virtualisation, 5G core deployments, and subscriber data sovereignty — built to meet TRAI and DoT requirements without compromising engineering flexibility.
Indian telecom operators handle subscriber data under TRAI's Data Privacy Regulations and DoT's security requirements. Public cloud creates a fundamental conflict: you can't achieve true data residency if your infrastructure provider has root access.
AravaliStack gives telecom and ISP operators a fully self-hosted NFV and cloud-native infrastructure — VNF lifecycle management, service chaining, and 5G core functions running on your own hardware, under your own policy.
TRAI Data Privacy Regulations, DoT security requirements, and CERT-IN guidelines — mapped to AravaliStack controls with audit-ready evidence generation.
From IITs to EdTech scale-ups — AravaliStack provides the infrastructure for higher education and learning platforms that must keep student data, research IP, and academic records inside India.
On-campus private cloud for research compute, HPC workloads, student portals, and administrative systems. Full control, UGC and NAAC compliance-ready.
Self-hosted infrastructure for learning management, video delivery, personalised recommendation ML, and assessment engines. Student data never leaves India.
HPC clusters, ML training environments, data lakes for longitudinal research — all self-hosted, with CERT-IN compliant security and full audit trails for grant compliance.
Self-hosted elastic infrastructure for retail and e-commerce — burst compute for peak seasons, self-hosted recommendation ML, PCI-DSS compliant payment data, and zero cloud egress surprises.
E-commerce platforms face 10x traffic spikes during sales events, PCI-DSS payment data requirements, and increasingly sophisticated recommendation and personalisation ML. Public cloud handles all of these — at a cost that scales unpredictably.
AravaliStack gives you elastic compute that scales on your hardware, PCI-DSS compliant storage for payment data, and a self-hosted ML stack that keeps your recommendation models — and your competitive advantage — inside your walls.
IRDAI compliance, actuarial ML that stays in-house, claims processing pipelines, and policyholder data sovereignty — built for Indian insurers who take their regulatory obligations seriously.
The Insurance Regulatory and Development Authority of India's data localisation requirements aren't optional. AravaliStack ensures every data record — policyholder PII, claims data, actuarial tables — stays within India and within your control.
Your pricing models, risk scoring algorithms, and fraud detection systems are your competitive advantage. AravaliStack keeps them on your infrastructure — not a shared cloud where the same tools could theoretically be available to a competitor.
Fleet data, warehouse edge inference, partner API management, and supply chain analytics — all running inside your perimeter. Full DPDP Act compliance, no egress surprises.
Real-time telematics, route optimisation ML, driver behaviour analytics — processed at edge nodes in your distribution hubs, unified in your own data platform.
Computer vision for inventory counting, conveyor anomaly detection, automated picking guidance — all processed on-site with no cloud latency or egress cost.
Self-hosted API gateway (Kong) for partner integrations — 3PLs, customs, port authorities, last-mile partners. Full audit trail, rate limiting, and SLA monitoring.
AravaliStack isn't only for large enterprises. If you're a scaling startup with real data obligations — payments, health, finance — we offer a path from cloud-native to self-sovereign without rebuilding your stack.
Public cloud pricing is designed for SMBs. AravaliStack's pricing is designed for organisations that have outgrown it. The crossover happens faster than you think.
Winning enterprise and government contracts requires demonstrable data sovereignty. AravaliStack makes that a technical fact, not a promise in a DPA.
Self-service provisioning, GitOps, cloud IDE, and a developer portal that feels like modern cloud — but running on infrastructure you own.
Deploy, manage, and extend AravaliStack for your enterprise clients. White-labelling, multi-tenant management, and a partner programme designed to grow your cloud practice with recurring revenue.
Indian enterprises are under pressure from regulators, boards, and CISOs to demonstrate data sovereignty. Most SIs don't have a sovereign cloud offering — they're reselling public cloud with a managed services wrapper.
AravaliStack gives your practice a genuine sovereign cloud product to take to market — with all the technical depth, compliance documentation, and engineering support to close enterprise deals.
Our partnership team will walk you through the business model, margins, and technical enablement programme.
Air-gapped deployments, classified workload isolation, TEMPEST-rated configuration options, and the contractual sovereignty guarantees that defence and critical national infrastructure programmes require.
AravaliStack deployments for defence and critical infrastructure are handled through a separate, classified engagement process. All engagements require verification of organisational identity and authorised procurement channel. Contact us for details.
AravaliStack is designed to operate with no external network connectivity. Every component — updates, licensing, telemetry — is designed for air-gapped operation. Manual update packages, offline licence validation, and completely self-contained operation.
Hardware-enforced isolation between classification levels. Separate compute pools, separate networks, separate storage — with cryptographic verification at every boundary. Policy enforcement at the kernel level, not the application layer.
AravaliStack's auto-scaling layer goes beyond Kubernetes HPA. KEDA brings event-driven scaling from Kafka queue depth, database row counts, or custom metrics. VPA right-sizes pods without manual tuning. Predictive scaling anticipates demand before it arrives.
Scale workloads to zero when idle. Scale instantly when a Kafka topic has messages, a queue is backing up, or a database table crosses a threshold. 60+ built-in scalers.
Automatically right-size CPU and memory requests based on actual usage. Eliminate the toil of manual resource tuning. VPA observes and recommends — or applies — in real time.
Standard HPA reacts to current load. AravaliStack's predictive layer analyses historical patterns to scale before demand arrives — so your users never see the lag.
AravaliStack's scaling policies are cost-aware. Set a hard cost ceiling per workload or team. The platform scales within that boundary — and alerts you when demand would breach it, rather than silently generating an overage.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: payment-processor
spec:
scaleTargetRef:
name: payment-worker
minReplicaCount: 0
maxReplicaCount: 50
triggers:
- type: kafka
metadata:
topic: payment-events
lagThreshold: "100"
consumerGroup: payments
AravaliStack's AIOps layer applies machine learning to your own platform telemetry — detecting anomalies before they become incidents, correlating root causes across hundreds of signals, and automating remediation for known failure patterns.
Unsupervised ML models trained on your baseline telemetry — CPU, memory, network, latency, error rates. Detects deviations from normal patterns 20–40 minutes before they become user-visible incidents.
When an incident fires, AIOps correlates alerts across compute, networking, storage, and application layers to surface the probable root cause — reducing mean time to diagnosis from hours to minutes.
For known failure patterns, AIOps executes remediation playbooks automatically — pod restarts, traffic rerouting, resource scaling — with a full audit trail of every automated action and a rollback mechanism.
AIOps analyses resource utilisation trends across all workloads to forecast when you'll need additional capacity — weeks in advance, not hours. Capacity recommendations are integrated into the cost intelligence dashboard.
Every AIOps model in AravaliStack trains exclusively on your platform's own telemetry. No data leaves your perimeter. No SaaS AIOps vendor has a window into your operations. The intelligence belongs to you.
AravaliStack includes a built-in enablement layer — sandbox environments, guided onboarding flows, interactive training labs, and role-based certification paths. A platform no one can use is just expensive infrastructure.
Every new team member gets an isolated sandbox cluster — real AravaliStack, real tools, no production risk. Sandboxes auto-expire after 7 days and cost is attributed to learning budget, not production workloads.
Role-based onboarding paths for platform engineers, developers, and operations teams. Step-by-step labs with real commands, expected output, and progress tracking — inside the platform, not a separate LMS.
Four certification tracks — Platform Administrator, Security Engineer, ML Operations, and Platform Architect. Practical assessments, not multiple choice. Certificates verifiable by your employer and clients.
We've seen too many enterprise platform deployments fail not because the platform was wrong, but because the team never got confident. AravaliStack's enablement layer is part of the platform — not a separate, optional add-on.
AravaliStack's advisory board brings together practitioners who have built and regulated India's most sensitive digital infrastructure. Their guidance shapes everything from product architecture to regulatory positioning.
35 years at RBI overseeing IT risk frameworks for systemically important banks. Authored the 2023 RBI Cloud Guidelines. Now advises on how AravaliStack maps to India's evolving financial sector data sovereignty requirements.
India's foremost academic expert on data protection law, DPDP Act interpretation, and government cloud policy. Contributed to the parliamentary committee review of the DPDP Bill. Advises AravaliStack on legal-technical compliance positioning and policy engagement.
Oversaw cybersecurity for India's largest bank — 500M+ customer records, 22,000 branches. Designed SBI's hybrid cloud security architecture and coordinated with CERT-In on incident response. Advises AravaliStack on zero-trust architecture, threat modelling, and enterprise CISO requirements.
Built and sold India's first hyperscaler migration practice, delivering 200+ enterprise cloud migrations across BFSI and government. Sat on the NASSCOM committee that defined India's first cloud security standards. Advises AravaliStack on enterprise GTM, SI partnerships, and the realities of enterprise procurement.
If you have deep domain expertise in Indian regulatory compliance, enterprise infrastructure, or critical sector operations and see strategic alignment with what we're building, we'd like to hear from you.
Answer 4 questions. Get a visual architecture diagram tailored to your industry, compliance needs, and team size — ready to share with your CTO or board.
Our solutions team will produce a detailed architecture document with hardware specs, configuration, and compliance mapping for your exact requirements.
6 questions about your workloads and team. We'll output a recommended server configuration, storage spec, and network topology — with cost estimates and a PDF you can send to procurement.
Set your RPO and RTO requirements. We'll output the recommended DR architecture, failover mechanism, replication strategy, and cost estimate — across all your critical workloads.
Click Indian regions to add deployment nodes. The planner calculates inter-node latency, recommends a topology, and estimates your inter-DC bandwidth requirements.
Select 2+ regions on the map to see topology recommendations.
Fill in 7 fields. We'll generate a branded PDF-ready report with your organisation's name, your numbers, and a 3-year financial projection your CFO can approve.
| Year | Public Cloud | AravaliStack | Saving |
|---|
Our solutions team will produce an auditor-grade version signed by our CFO with your exact infrastructure footprint.
AravaliStack's private preview programme gives engineering teams early access to features before GA — with direct access to the engineers building them.
Autonomous agents that diagnose platform anomalies, propose and execute remediation steps, and open post-mortems — with human-in-the-loop approval for critical actions.
Manage ArgoCD applications across 3–20 AravaliStack clusters from a single control plane — with per-cluster RBAC, policy inheritance, and centralised audit trail.
ML-driven cost forecasting at the namespace and team level — predicting 30/60/90-day spend with configurable alerts and automatic chargeback report generation.
We select 8–15 organisations per preview cohort. Criteria: existing AravaliStack customer or active POC, production use case, engineering team available for feedback sessions.
We've been through dozens of enterprise vendor assessments. Here are the questions procurement departments ask most often — answered in full, so your deal doesn't die in a due diligence queue.
Our legal and commercial team responds to procurement questions within 48 hours.
Save your security team 3–5 days. We've pre-answered the most common enterprise vendor security assessment questions below. Download as PDF or copy sections directly into your VSAQ or SIG Lite.
The full pack covers 80+ questions across 12 security domains — formatted for direct import into VSAQ, SIG Lite, and most enterprise vendor risk management platforms.
Some procurement processes require on-site visits, interviews with our CISO, or custom questionnaire formats. We accommodate all of these.
The DPDP Act 2023 creates a technical obligation, not just a legal one. Here's exactly how AravaliStack's architecture satisfies each key requirement — with evidence templates your DPO can use directly.
The Digital Personal Data Protection Act, 2023 is India's comprehensive data protection legislation. It came into force in August 2023 and establishes rights for data principals, obligations for data fiduciaries, consent requirements, data localisation mandates for certain categories of data, and penalties of up to ₹250 crore per violation. Every enterprise that processes personal data of Indian citizens is covered.
A 12-page template your DPO can complete to demonstrate DPDP Act readiness — with AravaliStack control references pre-filled.
The Reserve Bank of India's 2023 cloud guidance creates specific obligations for banks and NBFCs. AravaliStack is designed from first principles to satisfy these requirements — architecturally, not contractually.
RBI's guidance on cloud adoption (2023) requires regulated entities to ensure: data residency within India, unrestricted supervisory access, audit rights, concentration risk management, and exit strategy planning. Most critically, the RBI requires that Indian banks can demonstrate control over their data — not just a contractual promise from a foreign-headquartered cloud provider.
A 2-page checklist your IT Risk team can complete to document RBI cloud guidance compliance for your AravaliStack deployment.
We'll schedule a 45-minute technical briefing with your CISO and IT Risk team — covering RBI compliance positioning and answering any regulatory questions.
SEBI's 2023 circular on cloud adoption by regulated entities creates specific requirements for stock brokers, depositories, exchanges, and asset managers. AravaliStack maps directly to each.
SEBI's circular requires that regulated entities (stock exchanges, depositories, brokers, investment managers) ensure data sovereignty, maintain supervisory access for SEBI, implement robust cybersecurity for market data, and avoid single-point-of-failure in cloud infrastructure. Circular requires documented cloud strategy and annual board-level review.
We offer a dedicated 45-minute briefing for SEBI-regulated entities — covering our architecture, SEBI compliance mapping, and how to present this to your compliance officer and board.
AravaliStack Technologies Pvt Ltd holds ISO 27001:2022 certification — the international standard for information security management systems. Here's exactly what's in scope, who certified us, and what it means for your deployment.
The ISO 27001 certification covers the development, deployment, and support of the AravaliStack sovereign cloud platform, including:
The customer's own deployment of AravaliStack is not in scope of our certification. However, the platform architecture assists customers in achieving their own ISO 27001 compliance — and we provide a detailed ISO 27001 control mapping document to support your ISMS implementation.
A 20-page guide showing how AravaliStack controls map to each ISO 27001:2022 Annex A control — helping your ISMS team implement compliance faster.
RBI, SEBI, IRDAI, PCI-DSS, DPDP Act — AravaliStack is the only platform where compliance is architectural, not contractual. Every control, every audit trail, every data residency guarantee is technically enforced — not promised in a DPA.
RBI's 2023 cloud guidance fundamentally changed what Indian banks can tell their regulator about data sovereignty. The days of pointing to a cloud provider's DPA as evidence of compliance are over. RBI wants architectural proof.
AravaliStack gives you that architectural proof. Your data never leaves your infrastructure. Your audit log is yours. Your regulator can access it without routing through a foreign-headquartered vendor.
Central ministries, state departments, urban local bodies, and smart city SPVs — AravaliStack provides the platform for government data that belongs to India, managed by India, accountable to India.
e-Governance platforms, citizen data management, inter-ministry data exchange, and sensitive document management — all on infrastructure that the Ministry owns and controls.
Integrated Command and Control Centres (ICCC), urban IoT data, traffic management, utility monitoring, and citizen services — all running in the city's own data infrastructure.
State Data Centres, department portals, land records, revenue systems, welfare distribution, and CCTV/surveillance data — on infrastructure the state owns and the IT department controls.
Government entities can procure AravaliStack through Government e-Marketplace (GeM) or through NICSI. We support standard GFR procurement procedures and can provide RFP/bid documentation support.
Most DR is tested once a year. AravaliStack runs automated simulations continuously and gives you a live Readiness Score — so you know exactly where you stand before a real incident, not after.
Live data from your infrastructure. No manual reporting, no spreadsheets.
| Job Name | Resource | Provider | Status | Last Run |
|---|---|---|---|---|
| Nightly-DB-Backup | PostgreSQL · payments | AWS | Success | 2025-10-06 02:10 |
| Nightly-DB-Backup | PostgreSQL · payments | AWS | Success | 2025-10-06 02:10 |
| Nightly-DB-Backup | PostgreSQL · payments | AWS | Failed | 2025-10-06 02:10 |
| Nightly-DB-Backup | PostgreSQL · payments | AWS | Success | 2025-10-06 02:10 |
A continuously computed score (0–100) based on replication lag, last simulation result, RTO/RPO deviation, and configuration drift. Know your DR posture in real time.
Automated chaos simulations run against your actual cluster topology — Zone Down, Cluster Crash, Network Partition — with Pass/Fail, recovery time, and root cause logged automatically.
Policy-driven snapshots with configurable retention, AES-256 encryption, provider tagging, and immutable storage. Restore-tested automatically every 30 days.
Backup anomaly detection, excessive permission alerts, and policy drift monitoring — all surfaced in the same DR dashboard with severity scoring and recommended actions.
Backup jobs targeting any resource — PostgreSQL, Kafka, MinIO, object storage — across AWS, Azure, GCP, or on-premise, all managed from one dashboard.
Auto-generate DR evidence reports for RBI, IRDAI, ISO 22301, and DPDP Act obligations — pre-formatted for your auditor, generated on demand.
ML-powered spend forecasting, real-time anomaly detection with severity scoring, intraday cost charts, and a built-in provider comparison calculator. All on your own infrastructure — no data leaving your perimeter.
| Cloud Provider | Region | Current Spend | Trend | Budget Consumed | Resource Type | Status |
|---|---|---|---|---|---|---|
| AWS | East US | $3,120.40 | VM (EC2) | Approaching | ||
| AWS | East US | $3,120.40 | VM (EC2) | Approaching | ||
| AWS | East US | $3,120.40 | VM (EC2) | On Track |
| Provider | Spec | Monthly | 1-Year | 3-Year |
|---|---|---|---|---|
| AWS | 4 vCPU, 16GB RAM, 100GB | ₹122 | ₹963 (21% off) | ₹963 (21% off) |
| Azure | 4 vCPU, 16GB RAM, 100GB | ₹118 | ₹932 (21% off) | ₹932 (21% off) |
| AravaliStack | 4 vCPU, 16GB RAM, 100GB | ₹68 | ₹582 (28% off) | ₹462 (37% off) |
Department-level chargeback, invoice discrepancy detection, finance report generation, and tagging health — all in a single dashboard that your CFO and your finance team can actually use.
| Department | Allocated Cost | Shared Infra | Manual Adjust | Reconciliation |
|---|---|---|---|---|
| Retail Banking | 32% | High | Mitigated | ✓ Matched |
| Corporate Banking | 28% | Medium | Mitigated | ✓ Matched |
| Technology | 24% | Low | Pending | ⚠ Review |
| Operations | 16% | Low | Mitigated | ✓ Matched |
Self-hosted application catalogue, private VPN fabric, and container orchestration — all managed from one control plane on your infrastructure, with full audit trail and RBAC.
One-click deployment of 80+ pre-validated applications — databases, message queues, observability stacks, ML tools. All running on your hardware.
WireGuard-based self-hosted VPN with per-user and per-team access policies, split tunnelling, audit logs, and automatic certificate rotation.
Kubernetes on your hardware — with self-service namespace creation, RBAC, resource quotas, and GitOps deployment for every team.
Multi-site networking with Cilium/Calico CNI, Istio service mesh, SD-WAN integration, and hardware load balancing — all managed from your AravaliStack control plane.
Unified WAN management across your data centres with intelligent traffic routing, failover, and QoS policies.
mTLS encryption between all services by default, with traffic policies, circuit breaking, and distributed tracing built in.
L4/L7 load balancing with MetalLB, Kong, and hardware integrations — with health checks, sticky sessions, and SSL termination.
HashiCorp Vault deployment on your infrastructure with dynamic secrets, certificate authority, key rotation, and hardware security module (HSM) integration.
Time-limited database credentials, cloud API keys, and certificates generated on-demand — no static secrets anywhere in your environment.
Vault Transit engine provides encryption/decryption as an API — applications encrypt data without ever handling keys directly.
Internal PKI with automatic certificate issuance, rotation, and revocation — integrated with Istio for automatic mTLS.
80+ pre-validated Helm charts, operators, and integrations — deployed to your cluster in one click, with configuration templates, version management, and support SLAs.
Curated catalogue of enterprise applications — all tested on AravaliStack, with one-click deployment and automatic updates.
Every term a CTO, CISO, or infrastructure architect needs to evaluate, procure, and deploy sovereign cloud infrastructure — written for practitioners, not marketers. 71+ definitions covering PaaS, Kubernetes, zero trust, compliance, DevOps, and more.
AravaliStack puts every concept in this glossary into production — on your hardware, under your control.
A system completely isolated from public networks — no internet, no external APIs, no cloud connectivity.
An air-gapped deployment refers to an infrastructure configuration in which a computer system, network, or data centre is physically and logically isolated from any unsecured external network — most importantly, the public internet. The term originates from the military concept of an air gap: a literal physical separation between secure and insecure systems.
In enterprise technology, air-gapped deployments are the highest tier of network isolation. They are mandatory in contexts where data sensitivity, regulatory obligation, or threat models demand that no unauthorised data exfiltration is possible — not even through compromised software on an internet-connected host.
The primary driver is data sovereignty. In India, regulatory frameworks including RBI's guidelines on outsourcing of financial services, SEBI's cloud adoption framework, and the DPDP Act 2023 all contain provisions that effectively require certain categories of data to remain under the direct physical and logical control of the organisation. A cloud-hosted workload — even one claiming data residency — cannot satisfy these requirements because the cloud provider retains physical access to underlying hardware.
Secondary drivers include protection from nation-state threat actors, compliance with NCIIPC (National Critical Information Infrastructure Protection Centre) directives for critical infrastructure operators, and internal governance requirements in organisations handling classified or commercially sensitive information.
A true air-gap means: no inbound or outbound internet routing, no external DNS resolution, no public certificate authority chains, no SaaS-based monitoring or logging, and no external package registries. All software dependencies — container images, OS packages, Helm charts, ML model weights — must be mirrored into an internal registry before deployment. Updates must be delivered via physical media or dedicated secure transfer channels.
AravaliStack is designed from the ground up for air-gapped operation. Every component — container registry, package mirror, certificate authority, DNS, monitoring, identity, and logging — is self-contained. There are no phone-home telemetry calls, no licence validation endpoints, and no dependencies on external APIs. An AravaliStack deployment functions identically with or without an internet connection.
On-premise simply means the hardware is in a location you control — but the software running on it may still call out to the internet. Private cloud typically refers to a virtualised environment operated by a single organisation, but connectivity policies vary. Air-gapped is the strictest constraint: it specifies network isolation regardless of where the hardware lives. A government data centre, a hospital server room, or a bank's regulated compute zone can all be air-gapped.
AravaliStack supports fully air-gapped deployments out of the box — no licence servers, no telemetry, no external dependencies. Approved for use in NCIIPC-designated critical infrastructure environments.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A cloud delivery model that provides a managed platform — compute, networking, storage, middleware — so developers can build and deploy applications without managing underlying infrastructure.
Platform as a Service (PaaS) is one of the three foundational service models of cloud computing, alongside Infrastructure as a Service (IaaS) and Software as a Service (SaaS). A PaaS provider manages the underlying computing infrastructure — servers, storage, networking, operating systems, and middleware — and exposes a managed platform on top of which organisations can develop, run, and govern applications.
The classic PaaS promise is developer productivity: teams write application code and deploy it to the platform without needing to provision servers, configure databases, manage network security groups, or operate monitoring stacks. The platform handles all of that.
Public cloud PaaS offerings (Heroku, Google App Engine, AWS Elastic Beanstalk, Azure App Service) delivered on the productivity promise — but introduced a different set of problems for enterprises with serious data governance requirements. When a platform is operated by a third party, data leaves your control. The provider can access your workloads at the hardware layer. Your architecture becomes opinionated toward their proprietary APIs, making migration costly. And your operating costs are subject to egress fees, pricing changes, and availability decisions made in another country.
An on-premise PaaS delivers the same developer productivity benefits — managed Kubernetes, automated deployments, integrated monitoring, self-service databases, identity management — but on infrastructure that the organisation owns and controls. No data leaves the premises. No third-party has hardware access. Costs are predictable and capital-structured rather than variable and metered.
This model is particularly relevant in India under the DPDP Act 2023, RBI's data localisation requirements, SEBI's cloud adoption framework, and ABDM's health data governance standards — all of which impose obligations that are difficult or impossible to satisfy with a public cloud PaaS.
A production-grade on-premise PaaS must deliver: container orchestration (Kubernetes), service mesh and networking, identity and access management, secrets management, object storage, data streaming, ML infrastructure, developer self-service tooling, GitOps-based deployment automation, cost attribution, and integrated observability — all operated as a unified, maintained platform rather than a collection of independently managed open-source tools.
AravaliStack is an on-premise PaaS — all 8 platform domains (compute, security, networking, data, AI/ML, developer tooling, cost intelligence, and marketplace) delivered as a single, maintained platform on your hardware. Hyperscaler capabilities. Zero cloud dependency.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A security model that eliminates implicit trust — every user, device, and service must be verified continuously, regardless of network location.
Zero Trust Architecture (ZTA) is a security philosophy and design framework that replaces the traditional perimeter-based security model with one simple principle: never trust, always verify. The model was formalised by NIST in Special Publication 800-207, and has since become the baseline security expectation for regulated enterprise environments globally.
The traditional model assumed that anything inside the corporate network perimeter could be trusted. Zero trust rejects this assumption entirely — because the perimeter no longer exists in a meaningful sense (remote work, containerised workloads, multi-cloud, APIs), and because internal threats are statistically more dangerous than external ones.
1. Machine identity (not just user identity). Every service, pod, and process must have a cryptographic identity — not a shared secret or a static API key. The SPIFFE/SPIRE framework issues short-lived X.509 SVIDs (SPIFFE Verifiable Identity Documents) that expire in 1–4 hours, eliminating the risk of long-lived credential compromise.
2. Policy as code. Access decisions must be governed by machine-readable policies stored in version control — not manually configured firewall rules or group membership. OPA (Open Policy Agent) enables policy decisions to be audited, tested, and reviewed like software.
3. Mutual TLS everywhere. All service-to-service communication must be encrypted and mutually authenticated — meaning both sides prove their identity before any data is exchanged. A service mesh like Istio enforces this at the infrastructure layer, not the application layer.
4. Dynamic secrets. Databases, message queues, and APIs should issue short-lived credentials per session — not static passwords stored in environment variables. HashiCorp Vault's dynamic secrets engine generates credentials on demand and revokes them automatically.
Zero trust is not a product you buy. Vendors selling "zero trust" products almost universally mean user authentication products — ZTNA (Zero Trust Network Access) solutions that replace VPNs. These address one narrow slice of the problem (user identity) and ignore the far larger attack surface of service-to-service communication, secrets management, and policy enforcement. Buying a ZTNA product and calling it zero trust is the enterprise equivalent of installing a front door lock on a building with no walls.
Zero trust is the default security posture of AravaliStack — not a configuration option. All four pillars are built in: SPIFFE/SPIRE machine identities, OPA policy engine, Istio service mesh with mTLS enforcement, and Vault-issued dynamic secrets.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
An open-source container orchestration system that automates deployment, scaling, and management of containerised applications across a cluster of servers.
Kubernetes (K8s) is an open-source container orchestration platform originally developed by Google and donated to the Cloud Native Computing Foundation (CNCF) in 2014. It has become the de facto standard for running containerised workloads at scale in production environments.
At its core, Kubernetes solves the problem of running many containerised applications across many servers reliably — ensuring applications are always running, self-healing when they fail, scaling up when demand increases, and rolling out updates without downtime.
A Pod is the smallest deployable unit in Kubernetes — typically one container, sometimes a group of tightly coupled containers. A Deployment manages a set of identical Pods, ensuring the right number are running and handling rolling updates. A Service provides a stable network identity for a group of Pods. A Namespace creates a logical boundary within a cluster, used for multi-tenancy and resource isolation. A Node is a server (physical or virtual) that runs Pods.
For enterprises running workloads on their own hardware, Kubernetes provides cloud-like operational capabilities — automated scheduling, health checks, horizontal scaling, rolling deployments, and declarative configuration — without requiring a public cloud provider. This is the fundamental enabler of on-premise PaaS: you get the operational benefits of a cloud platform, on hardware you own.
The complexity, however, is real. A production Kubernetes deployment requires expertise in networking (CNI plugins, ingress controllers, network policies), storage (CSI drivers, persistent volumes), security (RBAC, admission controllers, pod security standards), observability (metrics, logs, traces), and upgrade management. This is why platforms like AravaliStack exist — to deliver managed Kubernetes as part of a complete platform rather than requiring each enterprise to assemble and operate it independently.
Kubernetes is widely used in Indian banking, insurance, and healthcare technology — but almost always managed by the IT team as a raw infrastructure component rather than as part of a governed platform. This creates significant operational risk: there is no separation between the platform team and application teams, security configurations are inconsistent, and compliance posture is difficult to audit. A platform layer above Kubernetes — with enforced network policies, admission controls, namespace isolation, and GitOps governance — is required for RBI and SEBI compliance.
AravaliStack is built on Kubernetes — with all the platform governance, security policies, and operational tooling pre-configured. You get a production-hardened Kubernetes environment, not a raw cluster to configure yourself.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
An operational model where Git is the single source of truth for infrastructure and application state — all changes happen through pull requests, not manual commands.
GitOps is an operational model for managing infrastructure and application deployments where a Git repository is the authoritative, single source of truth for the desired state of the entire system. Changes to infrastructure or applications are made by committing to Git — and an automated reconciliation agent continuously ensures that the live system matches the declared state in the repository.
The term was coined by Weaveworks in 2017, but the underlying principle — declarative infrastructure, version-controlled state, automated convergence — builds on decades of infrastructure-as-code thinking.
In a GitOps model: (1) An engineer edits a manifest file (YAML, Helm values, Terraform) and opens a pull request. (2) The PR goes through code review and automated testing. (3) The PR is merged to the main branch. (4) A GitOps controller (such as Flux CD or Argo CD) detects the change and applies it to the live environment. The live system is pulled to match the desired state — not pushed by a deployment script. This pull-based model is more secure because the cluster initiates outbound connections to Git, rather than accepting inbound deployment commands.
In regulated industries — banking, insurance, healthcare — every change to production infrastructure must be auditable. With a traditional push-based deployment model (kubectl apply from a CI pipeline, or worse, manual changes), the audit trail is incomplete: you can see that a deployment happened, but not always who approved it, what changed, or how to roll it back to a known-good state.
With GitOps, the Git commit history is the audit trail. Every change has an author, a reviewer, a timestamp, and a diff showing exactly what changed. Rollback is a git revert. RBI's requirements for change management and audit logging are satisfied without any additional tooling.
GitOps can govern more than application deployments. AravaliStack uses GitOps for: infrastructure manifests (cluster configuration, node pools), security policies (OPA rules, network policies), cost budgets (OpenCost budget declarations), ML training jobs (reproducible experiment definitions), and certificate management. When Git is the single control plane, every change to every layer of the platform is auditable, reviewable, and reversible.
GitOps is the only change mechanism in AravaliStack. There is no kubectl exec in production, no dashboard-based config changes, no deployment scripts with implicit state. Git is the control plane.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The principle that data is subject to the laws and governance of the country in which it is collected or stored — and the right of an organisation to maintain physical and legal control over its data.
Data sovereignty is both a legal concept and an architectural requirement. As a legal concept, it holds that data is subject to the laws of the jurisdiction in which it physically resides — meaning that data stored on servers in a foreign country is subject to that country's laws, including laws permitting government access. As an architectural requirement, it describes the need for organisations to maintain actual physical and logical control over their data — not merely contractual assurances from a third-party provider.
India has developed one of the world's most explicit data sovereignty frameworks across multiple sectors:
The RBI has required, since 2018, that all payment system data be stored exclusively in India. This applies to all payment system operators and their service providers. Subsequent circulars have extended similar requirements to NBFCs and banks' core banking data.
The SEBI cloud adoption framework (2023) requires that critical data, including trading data, investor records, and audit trails, be stored and processed within India. Overseas storage requires prior approval and strict contractual frameworks.
The DPDP Act 2023 empowers the Central Government to restrict cross-border transfer of personal data to certain countries — establishing a data localisation framework that will apply to all entities processing personal data of Indian residents.
The ABDM (Ayushman Bharat Digital Mission) framework requires that all health data — including ABHA-linked records — be stored within India and under governance frameworks that prevent foreign access.
A critical distinction is between contractual data sovereignty (a cloud provider contractually commits to storing data in India) and technical data sovereignty (the data physically resides on hardware you own, with no third party having access). Contractual sovereignty does not protect against foreign government subpoenas served on the cloud provider, hardware-level access by cloud provider employees, or service discontinuation decisions. Technical sovereignty — on-premise infrastructure — is the only way to guarantee that data remains under your control regardless of geopolitical or commercial developments.
AravaliStack is architected for technical data sovereignty. Your data resides on hardware you own. No AravaliStack component calls home, sends telemetry, or requires external API access. DPDP Act, RBI, SEBI, and ABDM compliant by design.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
An architecture where a single platform instance serves multiple independent organisations or business units, with strict isolation between tenants.
Multi-tenancy describes a software architecture in which a single instance of a platform serves multiple distinct customers or organisational units (tenants), where each tenant's data, configuration, and workloads are isolated from every other tenant. The platform itself is shared; the data and compute environments are not.
For Managed Service Providers (MSPs) deploying AravaliStack for multiple enterprise customers, multi-tenancy eliminates the need to operate a separate cluster per customer — which would be operationally untenable at scale. For large enterprises, multi-tenancy allows different business units, subsidiaries, or project teams to share platform infrastructure with full isolation and independent billing.
Namespace isolation alone — Kubernetes namespaces separating tenant workloads — is insufficient for regulated environments. Production multi-tenancy requires isolation at seven layers:
Network isolation: Default-deny NetworkPolicies ensure that pods in one tenant namespace cannot send packets to pods in another — even if misconfigured. CNI plugins (Calico/Cilium) enforce this at the kernel level.
Compute isolation: Dedicated node pools with taints and tolerations ensure that high-security tenants run on hardware that is never shared with lower-trust workloads.
Storage isolation: Separate Persistent Volumes with tenant-specific encryption keys — meaning that a compromised storage admin cannot read another tenant's data.
Identity isolation: Each tenant has its own identity realm with its own user federation, SSO configuration, and role hierarchy.
Secrets isolation: A dedicated secrets namespace per tenant ensures that a tenant's application cannot read another tenant's credentials, even if the Kubernetes API is compromised.
Billing isolation: Per-namespace cost attribution with per-tenant invoicing — MSPs can invoice customers for their actual platform consumption.
Governance isolation: Role-based access control at three levels — platform operator, tenant administrator, tenant developer — with Git-managed permission definitions.
AravaliStack's multi-tenancy stack enforces isolation at all seven layers. MSPs can onboard new tenants in under 30 minutes — with full network, compute, storage, identity, secrets, billing, and governance isolation provisioned automatically.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
An infrastructure layer that handles all service-to-service communication in a microservices architecture — providing observability, security, and traffic management without application code changes.
A service mesh is a dedicated infrastructure layer for managing all communication between microservices in a distributed system. It is implemented as a set of lightweight network proxies (sidecars) deployed alongside each service, which intercept all inbound and outbound traffic — without requiring any changes to the application code.
Mutual TLS (mTLS): Every service-to-service connection is encrypted and mutually authenticated. Both the client and server must present valid certificates before any data is exchanged. This eliminates a broad class of attacks including man-in-the-middle interception, credential replay, and lateral movement after initial compromise.
Traffic management: Intelligent routing rules — canary deployments (send 5% of traffic to a new version), circuit breaking (stop sending traffic to a failing service), retries (automatically retry failed requests), and timeout enforcement — without writing this logic in application code.
Observability: Every request — its latency, error rate, payload size, and route — is automatically instrumented without application code changes. This provides the golden signals (latency, traffic, errors, saturation) required for SRE-standard observability.
Policy enforcement: Authorisation policies specify which services are allowed to communicate with which other services — rejecting all traffic not explicitly permitted. This implements zero-trust network segmentation within the cluster.
For RBI-regulated financial entities and ABDM-compliant healthcare systems, the requirement to encrypt all data in transit extends to internal service-to-service communication — not just external-facing APIs. A service mesh is the only practical mechanism to enforce this at scale without instrumenting every application individually. The audit trail generated by a service mesh (every request logged with source, destination, protocol, and outcome) also satisfies the transaction monitoring and audit requirements of multiple Indian regulatory frameworks.
AravaliStack includes a production-configured service mesh with mTLS enforced by default — no opt-out. All service-to-service traffic is encrypted and authenticated. Authorisation policies are managed as code in Git.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
India's Digital Personal Data Protection Act — the primary federal law governing collection, processing, storage, and transfer of personal data of Indian residents.
The Digital Personal Data Protection Act, 2023 (DPDP Act) is India's first comprehensive federal data protection legislation, enacted in August 2023. It establishes the framework for how personal data of Indian residents may be collected, processed, stored, and transferred — by both Indian and foreign entities that process such data.
Consent as the primary lawful basis. Personal data may generally be processed only with the free, specific, informed, and unambiguous consent of the data principal (the individual whose data is being processed). Consent must be obtained before processing, must be as easy to withdraw as to give, and must be maintained in a verifiable form.
Data Fiduciary obligations. Entities that determine the purpose and means of processing (Data Fiduciaries — equivalent to GDPR's "controllers") must maintain data accuracy, implement security safeguards, delete data when no longer necessary, and establish a grievance redressal mechanism. Significant Data Fiduciaries (to be notified by the government) face additional obligations including data protection impact assessments and audits.
Data Principal rights. Individuals have the right to access a summary of their data, correct inaccurate data, erase data (right to be forgotten), nominate a person to exercise rights on their behalf, and raise grievances with both the Data Fiduciary and the Data Protection Board of India.
Cross-border transfer restrictions. The Central Government may restrict transfer of personal data to certain countries or territories. The specific list of permitted and restricted countries has not yet been notified as of early 2026, but the framework is in place.
Penalties. The DPDP Act establishes significant financial penalties — up to ₹250 crore per instance of personal data breach, and up to ₹200 crore for failure to notify breaches. The Data Protection Board has adjudicatory powers.
The DPDP Act's data localisation provisions — combined with the practical need to demonstrate control over personal data processing — make on-premise infrastructure significantly easier to comply with than cloud-based alternatives. When data resides on hardware you control, the Data Fiduciary relationship is straightforward. When data is processed on a third-party cloud, the Fiduciary/Processor relationship must be contractually established, audited, and maintained for every processing activity.
AravaliStack is architected for DPDP compliance. Data processing occurs entirely within your infrastructure. Data Principal rights workflows, consent management APIs, and breach notification procedures are available as platform capabilities.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
Managing and provisioning infrastructure through machine-readable configuration files rather than manual processes or interactive configuration tools.
Infrastructure as Code (IaC) is the practice of defining, provisioning, and managing computing infrastructure — servers, networks, databases, load balancers, security groups — using code and configuration files rather than manual processes, point-and-click UIs, or ad hoc scripts. Infrastructure definitions are stored in version control (Git), reviewed like software, and applied in an automated, repeatable manner.
Manual infrastructure management has three fundamental problems: it is error-prone (humans make mistakes, especially under pressure), it is not auditable (who changed what, when, and why is often unknown), and it is not reproducible (recreating an environment from scratch is difficult and inconsistent). IaC addresses all three: code is precise, Git commits are auditable, and code can be applied identically to any number of environments.
IaC typically refers to provisioning infrastructure — creating resources (Terraform, Pulumi, CloudFormation). Configuration management (Ansible, Chef, Puppet) refers to configuring existing servers. GitOps is an operational model that applies IaC principles specifically to Kubernetes and cloud-native environments, using a Git repository as the control plane and an agent that continuously reconciles live state to declared state. These are complementary: in a mature platform, IaC provisions the underlying infrastructure, and GitOps manages the application and platform layer running on it.
For RBI, SEBI, and NCIIPC compliance, IaC is not just a best practice — it is effectively mandatory. Change management requirements specify that all production changes must be documented, approved, tested, and auditable. A manual change made directly on a production server cannot satisfy these requirements. An IaC commit in Git — with an associated PR, reviewer approval, automated tests, and deployment log — satisfies all of them.
All AravaliStack components are defined as code. Platform configuration, security policies, network topology, cost budgets, and ML environments are all IaC — managed through Git, reviewed through pull requests, applied by the GitOps controller.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A lightweight, portable package containing an application and all its dependencies — isolated from the host operating system using Linux kernel features.
A container is a standardised unit of software packaging that bundles an application together with all of its dependencies — libraries, configuration files, runtime environment — into a single portable artefact that runs consistently regardless of the underlying infrastructure. Containers are isolated from one another and from the host OS using Linux kernel features (namespaces and control groups), but they share the host kernel — making them far more lightweight than virtual machines.
A virtual machine (VM) virtualises an entire computer, including the hardware layer, and runs a complete guest operating system. A VM image is typically gigabytes in size and takes minutes to start. A container virtualises only the application environment, sharing the host OS kernel. Container images are typically tens to hundreds of megabytes and start in seconds or milliseconds. The tradeoff is isolation depth: VMs provide stronger isolation (a separate kernel per VM), while containers provide stronger density and portability.
Docker popularised containers and the image format from 2013 onward. The Open Container Initiative (OCI) subsequently standardised the image format and runtime specification — meaning that container images built with Docker can run on any OCI-compliant runtime (containerd, CRI-O, etc.). Kubernetes uses OCI-compliant runtimes and does not depend on Docker directly.
Containers introduce a distinct security posture. Because containers share the host kernel, a container escape vulnerability (a bug that allows code in the container to access the host) has broader impact than a VM escape. Hardening measures — read-only filesystems, non-root users, seccomp profiles, AppArmor/SELinux policies, admission controllers blocking privileged containers — are required for production security. A platform layer (like AravaliStack) enforces these policies uniformly so individual application teams do not need to configure them.
AravaliStack runs all workloads as containers managed by Kubernetes. The platform enforces container security policies — non-root, read-only root filesystems, no privilege escalation — across all workloads via admission controllers.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The ability to understand the internal state of a system by examining its external outputs — metrics, logs, and traces.
Observability is the property of a system that allows its internal state to be inferred from its external outputs. In distributed computing, the term refers to the engineering practice of instrumenting systems to produce sufficient telemetry data — metrics, logs, and distributed traces — to diagnose any failure or performance issue without requiring access to the system's internals.
Metrics are numeric measurements of system behaviour over time — request rate, error rate, CPU utilisation, memory usage, queue depth. They are efficient to store and query, and excellent for alerting on known failure modes. Metrics answer: "Is the system behaving normally right now?"
Logs are timestamped, structured records of discrete events — a request received, an error thrown, a job completed. They provide the detail needed to understand what happened in a specific sequence. Logs answer: "What exactly happened at 14:32:07?"
Traces (distributed traces) follow a single request as it flows through multiple services — recording the duration and outcome of each hop. In a microservices architecture, a single user action may invoke dozens of services; traces make this visible. Traces answer: "Which service was the bottleneck, and why?"
Monitoring is the practice of watching known metrics and alerting when they exceed thresholds — it tells you that something is wrong. Observability is the property that allows you to understand why something is wrong — even if you have never seen that failure mode before. A well-monitored but poorly observable system can tell you the error rate is high but not why. A highly observable system allows you to trace the root cause through logs, traces, and metrics correlation.
RBI's guidelines on IT governance and risk management, and SEBI's operational resilience requirements, effectively mandate observability as a compliance requirement — not just an engineering best practice. The ability to demonstrate system behaviour retrospectively (for audit and incident investigations) requires comprehensive, retained, tamper-evident logs and metrics.
AravaliStack ships a complete observability stack — metrics collection, log aggregation, distributed tracing, and alerting — pre-configured for all platform components. All telemetry stays within your infrastructure.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The Reserve Bank of India's framework governing how regulated financial entities may adopt cloud computing — including data localisation, security, exit management, and vendor risk requirements.
The Reserve Bank of India (RBI) has issued a series of guidelines and master directions that collectively govern cloud adoption by regulated entities — including commercial banks, NBFCs, payment system operators, and urban cooperative banks. These guidelines reflect the RBI's consistent position that technology adoption must not compromise data sovereignty, operational resilience, or supervisory access.
Data localisation. Regulated entities must store all data relating to payment systems exclusively in India. For banks, core banking data, customer personal information, and transaction records must reside in India. Storing this data on servers outside India — even temporarily, for processing — requires prior approval and is subject to strict conditions.
Supervisory access. The RBI must be able to access data held by regulated entities or their service providers. This is a significant constraint on cloud adoption: if data is processed on a foreign cloud infrastructure, ensuring unimpeded supervisory access requires complex contractual arrangements that may not be honoured in all jurisdictions.
Vendor risk management. Regulated entities must assess and manage concentration risk with cloud providers. Over-dependence on a single cloud provider — particularly a foreign one — is identified as a systemic risk. Entities must maintain viable exit strategies and demonstrate the ability to migrate workloads within a defined timeframe.
IT governance. The RBI's IT Framework for NBFCs and similar directions for banks require that all material technology changes — including cloud migration — be approved by the Board or a Board-level committee, with documented risk assessments and business continuity plans.
Taken together, RBI's guidelines effectively require that critical banking workloads either run on-premise or on private cloud infrastructure within India, with demonstrable data sovereignty and supervisory access. Public cloud can be used for non-critical workloads, but the regulatory overhead of demonstrating compliance — third-party audits, contractual arrangements, supervisory access frameworks — is substantial. For most regulated entities, on-premise infrastructure for critical workloads is the more practical compliance path.
AravaliStack is designed to the RBI's requirements: on-premise, India-hosted, with no foreign data flows, supervisory access APIs, and audit-ready architecture. Deployed in production at RBI-regulated banking entities.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The set of policies, tools, and procedures that enable an organisation to restore critical IT systems and data after a catastrophic event.
Disaster Recovery (DR) is the organisational capability to restore critical technology systems and data to operational status following a catastrophic event — whether a natural disaster (flood, fire, earthquake), a human error (accidental deletion, misconfiguration), a cyber attack (ransomware, destructive malware), or an infrastructure failure (power outage, hardware failure at scale).
Recovery Time Objective (RTO) is the maximum acceptable time between a disaster and the restoration of service. If your RTO is 4 hours, your DR plan must restore all critical systems within 4 hours of an incident.
Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time. If your RPO is 1 hour, you must be able to recover to a state no more than 1 hour before the disaster — meaning backups or replication must run at least every hour.
RTO and RPO define the engineering requirements for your DR architecture. Lower values require more investment: active-active multi-site architectures can achieve RTO of seconds and RPO of zero, but at significant cost. Backup-and-restore architectures are cheaper but may have RTO of hours and RPO of 24 hours.
Backup and restore: Data is backed up to a separate location. Recovery involves restoring from backup and rebuilding the environment. Lowest cost, highest RTO/RPO.
Pilot light: A minimal version of the environment runs continuously in a secondary site (just the core components). In a disaster, the remaining components are activated. Moderate cost and RTO.
Warm standby: A scaled-down version of the full environment runs continuously and is synchronised with the primary. Recovery involves scaling up the secondary. Lower RTO, higher cost.
Active-active: Full production capacity runs in multiple sites simultaneously. Traffic is distributed across all sites. Failover is automatic and seamless. Highest cost, near-zero RTO/RPO.
Most DR plans are tested rarely or not at all. When they are tested, the test is usually a theoretical walkthrough rather than an actual failover exercise. This is the single most dangerous gap in enterprise IT risk management — the only way to know a DR plan works is to execute it against production systems. Platforms that simulate DR (chaos engineering, automated failover exercises) close this gap.
AravaliStack includes automated disaster recovery simulation — Velero-based backups, cross-region replication, and chaos engineering tooling that validates DR plans by running real failover exercises, not tabletop simulations.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A set of practices combining software development and IT operations to shorten the systems development lifecycle and deliver software continuously and reliably.
DevOps is a cultural and engineering movement that brings together software development (Dev) and IT operations (Ops) teams — historically siloed — to work collaboratively toward the shared goal of delivering software faster, more reliably, and with better quality. DevOps is not a job title, a tool, or a methodology in the strict sense — it is a set of practices, cultural norms, and technical capabilities that enable continuous delivery.
Continuous Integration (CI): Developers merge code changes to a shared repository frequently — multiple times per day. Each merge triggers automated tests that validate the change, catching integration problems early rather than at the end of a sprint.
Continuous Delivery (CD): The software is always in a deployable state. Every commit that passes automated tests is automatically deployed to a staging environment and can be deployed to production with a single action (or automatically in Continuous Deployment).
Infrastructure as Code: Infrastructure is defined and managed as code — enabling reproducible, auditable environment creation and eliminating the "works on my machine" problem.
Monitoring and feedback: Production systems are continuously monitored, with feedback flowing back to development teams. Incidents trigger postmortems that drive improvements to the software and the deployment process.
Adoption of DevOps in Indian banking and financial services has been slower than in technology sectors, primarily due to: (a) the perception that RBI's change management requirements are incompatible with continuous deployment; (b) legacy mainframe-centric architectures; and (c) risk-averse organisational cultures. In practice, DevOps and RBI compliance are compatible — GitOps-based continuous delivery with automated testing and full audit trails satisfies change management requirements more rigorously than traditional manual change management processes.
AravaliStack's developer platform includes CI/CD pipelines, developer self-service environments, automated testing frameworks, and GitOps controllers — enabling regulated enterprises to adopt DevOps without compromising their compliance posture.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
Physical servers on which software runs directly — without a hypervisor or virtualisation layer between the software and the hardware.
Bare metal refers to physical computing hardware — servers — on which software runs directly, without an intervening virtualisation layer (hypervisor). Bare metal deployments contrast with virtualised environments where physical servers run multiple virtual machines, each sharing underlying hardware resources.
On a virtualised server, a hypervisor (VMware ESXi, KVM, Hyper-V) creates and manages virtual machines. Each VM has a virtual CPU, virtual RAM, and virtual storage — mapped to physical resources by the hypervisor. This enables flexible resource allocation and strong isolation between workloads, but introduces CPU overhead (typically 5–15%), memory overhead (the hypervisor itself consumes memory), and latency (additional layer of abstraction for I/O).
On bare metal, there is no hypervisor. The OS and applications have direct access to physical CPUs, RAM, and storage. Performance is maximally efficient, and there is no overhead from virtualisation. The tradeoff is density: bare metal typically runs one workload per server, while virtualisation enables many workloads on shared hardware.
Bare metal is appropriate for: latency-sensitive applications (high-frequency trading, real-time fraud detection); GPU-intensive workloads (ML training, inference at scale) where virtualisation overhead is prohibitive; security-sensitive environments where hypervisor-layer vulnerabilities are an unacceptable risk; and high-throughput storage and networking workloads where I/O performance is critical.
Kubernetes can run on bare metal — and this is increasingly common in enterprise environments that want cloud-native orchestration without the performance cost of virtualisation. The challenge is that bare metal provisioning (adding or replacing servers) is a physical process, unlike the API-driven instance provisioning in a cloud environment. Platforms that abstract bare metal provisioning — automated BIOS configuration, OS installation, cluster joining — close this operational gap.
AravaliStack runs natively on bare metal — with automated provisioning, cluster formation, and hardware lifecycle management. No hypervisor required. Direct hardware access for GPU workloads, NVMe storage, and high-throughput networking.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
An architecture combining on-premise infrastructure with one or more public clouds — with workloads able to move between environments based on policy.
A hybrid cloud architecture combines on-premise or private cloud infrastructure with one or more public cloud environments (AWS, Azure, GCP), connected through a unified management and networking layer that enables workloads, data, and services to interoperate across environments.
For regulated Indian enterprises, the question is not whether to use the cloud — it is which workloads belong where. The answer is almost always a hybrid: regulatory and data-sensitive workloads on-premise (under direct control, DPDP/RBI compliant), with burst capacity, disaster recovery, and non-sensitive workloads on public cloud.
A well-designed hybrid architecture gives you: sovereignty where it is legally required (core banking, patient records, payment data), elasticity where it is commercially beneficial (seasonal traffic spikes, development environments), and resilience through geographic distribution and provider diversity.
Hybrid cloud requires: a common control plane that manages resources across both environments from a single interface; consistent networking (VPN or dedicated interconnect between on-premise and cloud); unified identity management (SSO that works in both environments); consistent security policies; and a common deployment model so that applications can run in either environment without modification.
Without a unified control plane, "hybrid cloud" is just two separate environments that share a billing team — the operational overhead of managing two completely different technology stacks negates the architectural benefits.
AravaliStack provides native AWS and GCP hybrid integration — managing cloud resources from the same control plane as on-premise. Workload placement policies, cost attribution, and security posture are consistent across both environments.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The charge cloud providers apply to data transferred out of their network — one of the primary mechanisms by which cloud lock-in is enforced financially.
Egress cost (or data egress fee) is the charge that public cloud providers apply to data transferred out of their network — to the internet, to another cloud provider, or to an on-premise environment. Critically, cloud providers typically charge nothing or very little for data transferred into their network (ingress), but charge per-gigabyte fees for data leaving (egress).
AWS charges between $0.08 and $0.09 per GB for data egress to the internet (as of 2025). GCP charges $0.08 per GB. Azure charges $0.087 per GB. For organisations processing terabytes or petabytes of data — financial transaction records, healthcare imaging, ML training datasets — egress fees are not a line item; they are a primary operating cost.
A mid-sized bank with 10 TB of data movement per month pays approximately $800–$900/month in egress fees alone — before compute, storage, or any other charges. A healthcare organisation with medical imaging data faces much higher volumes. The annual egress bill can easily exceed the capital cost of equivalent on-premise hardware.
Egress pricing serves a structural purpose: it makes it expensive to leave a cloud provider or to maintain a multi-cloud architecture where data moves between providers. The higher your egress bill, the higher the switching cost. This is the financial manifestation of vendor lock-in — not contracts, not proprietary APIs, but the brute economic cost of moving your data.
Regulators globally are beginning to address this. The EU's Data Act (2024) includes provisions requiring cloud providers to facilitate switching, including reducing or eliminating egress fees when customers are switching providers. Similar provisions are expected in Indian cloud regulatory frameworks.
AravaliStack customers pay ₹0 in egress fees. Your data moves between your own servers, over your own network. No per-gigabyte metering, no bill surprises, no financial lock-in.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The secure storage, access, rotation, and auditing of credentials, API keys, certificates, and other sensitive configuration values used by applications and services.
Secrets management is the discipline of securely handling the sensitive configuration values that applications need to function — database passwords, API keys, TLS certificates, encryption keys, SSH keys, OAuth client secrets, and any other credential or secret that must not be exposed to unauthorised parties.
The most common approach to secrets management in enterprise applications is also the worst: hardcoded secrets in source code, or secrets stored in environment variables or configuration files that are checked into Git. GitHub alone scans billions of commits per year and regularly detects millions of exposed secrets — AWS access keys, database passwords, API tokens — committed by developers who did not realise the implications.
The second most common approach is slightly better but still dangerous: secrets stored in a central configuration management system (Ansible Vault, Chef Encrypted Data Bags, Kubernetes Secrets) with long-lived credentials that are rarely rotated.
The correct model for secrets management in a zero-trust environment is dynamic secrets: short-lived credentials generated on demand for each application session, specific to the requesting service, and automatically revoked when the session ends. A database credential issued dynamically exists for the duration of a connection and is then deleted — there is nothing to steal, nothing to rotate manually, and no blast radius if a credential leaks.
Vault (HashiCorp's secrets engine) implements this model: it integrates with databases, cloud IAM systems, certificate authorities, and SSH, and issues dynamic credentials with configurable TTLs. AravaliStack includes Vault as a platform component, pre-integrated with all platform services.
RBI's IT governance framework, SEBI's cybersecurity guidelines, and CERT-In's directions all reference the need for robust credential management. Periodic rotation of service account passwords, audit trails of credential access, and separation of duties in secrets management are common requirements. A centralised secrets management platform with dynamic credential issuance satisfies all of these simultaneously.
AravaliStack includes a centralised secrets management engine with dynamic credential issuance, automatic rotation, and full audit trails. No static passwords in config files. No manually managed secrets.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A method of restricting system access to authorised users based on their role within an organisation — users are assigned roles, and roles are assigned permissions.
Role-Based Access Control (RBAC) is an access control model in which permissions to perform operations (read, write, execute, delete) on resources (files, APIs, databases, cluster namespaces) are assigned to roles rather than directly to individual users. Users are then assigned to roles, and inherit the permissions of those roles. This intermediate layer — the role — makes permission management tractable at enterprise scale.
Discretionary Access Control (DAC): Resource owners control access to their resources individually. Flexible but difficult to audit and enforce at scale (Unix file permissions are DAC).
Mandatory Access Control (MAC): Access decisions are made by a central authority based on security labels. Used in highly classified environments (government, defence). Inflexible for commercial enterprise use.
Attribute-Based Access Control (ABAC): Access decisions consider multiple attributes — user attributes, resource attributes, environment conditions (time of day, location). More expressive than RBAC but more complex to manage.
RBAC is the dominant model in enterprise software because it maps naturally to organisational structures and is auditable: you can enumerate who has access to what by listing role assignments.
Kubernetes has a built-in RBAC system that controls access to the Kubernetes API — which in turn controls everything in the cluster. Subjects (users, service accounts) are bound to ClusterRoles or namespace-scoped Roles via RoleBindings. Every API call is checked against the RBAC policy. In a multi-tenant platform, namespace-scoped RBAC ensures that a user in Tenant A's namespace cannot perform operations in Tenant B's namespace.
RBAC enables least-privilege access — giving each user and service exactly the permissions they need, and no more. This is a core principle of zero trust: if a credential is compromised, the blast radius is limited to the permissions of the compromised role. A developer credential that cannot delete production databases limits the impact of a supply chain attack or phishing incident.
AravaliStack implements RBAC at three levels: platform operator, tenant administrator, and tenant developer. All role definitions are managed as code in Git and auditable. Fine-grained namespace RBAC prevents cross-tenant access.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
An approach to building and running applications that exploits the advantages of the cloud computing delivery model — containers, microservices, dynamic orchestration, and continuous delivery.
Cloud native describes an approach to designing, building, and operating applications that is architected to take full advantage of dynamic, distributed, automated infrastructure — whether on a public cloud, private cloud, or on-premise platform. The Cloud Native Computing Foundation (CNCF) defines cloud-native as: "Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach."
Containerised: Applications are packaged as containers — portable, lightweight, and consistent across environments.
Microservices architecture: Applications are decomposed into small, independently deployable services — each responsible for a specific business capability, communicating via APIs.
Dynamically orchestrated: Container orchestrators (Kubernetes) automatically schedule, scale, and heal application components.
Declarative configuration: System state is declared rather than scripted — you describe what you want, and the platform figures out how to achieve it.
Observable: Applications emit metrics, logs, and traces that allow operators to understand their behaviour in production.
A critical misconception is that "cloud native" means "public cloud." The cloud-native architectural patterns — containers, Kubernetes, GitOps, observability, microservices — are infrastructure-agnostic. They run as well on-premise as on AWS. The confusion arises because these patterns were pioneered by public cloud companies (Google's internal Borg system led to Kubernetes), but there is no technical dependency on a public cloud provider. AravaliStack delivers cloud-native capabilities on infrastructure you own.
AravaliStack is a cloud-native on-premise platform. Every cloud-native capability — containers, Kubernetes, GitOps, service mesh, observability, CI/CD — runs on your hardware, under your control.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The practice of applying DevOps principles to machine learning — automating the ML lifecycle from data preparation to model deployment and monitoring.
MLOps (Machine Learning Operations) is the practice of applying DevOps engineering principles to machine learning systems — specifically, to the complete ML lifecycle: data ingestion, feature engineering, model training, evaluation, deployment, monitoring, and retraining. It emerged as a discipline because the operational challenges of ML systems are substantially different from — and more complex than — traditional software systems.
A traditional software system fails in predictable ways: it crashes, it returns an error, it times out. A machine learning model fails silently — it continues to return predictions, but the predictions degrade over time as the real-world distribution of inputs shifts away from the training distribution (a phenomenon called model drift or data drift). Detecting and responding to this requires continuous monitoring of model outputs, not just system metrics.
Additionally, ML experiments are not deterministic in the way that software builds are. The same training code run twice may produce different models depending on random initialisation, data ordering, and hardware. Reproducibility requires logging hyperparameters, dataset versions, environment specifications, and random seeds — a set of concerns that traditional software CI/CD does not address.
Experiment tracking: Logging all parameters, metrics, and artefacts from every training run — so that experiments can be compared, reproduced, and audited.
Model registry: A versioned catalogue of trained models — their lineage (what data and code produced them), evaluation metrics, and deployment status.
Automated pipelines: Reproducible, scheduled pipelines for data processing, model training, and evaluation — triggered by new data, schedule, or performance degradation.
Model serving: Scalable, low-latency serving of models via standardised APIs — with traffic management for canary deployments and A/B testing.
Monitoring: Continuous tracking of prediction distributions, data drift, feature drift, and model performance metrics — with alerting when drift exceeds thresholds.
For Indian financial entities using ML for credit scoring, fraud detection, or KYC, RBI's guidelines on model risk management effectively require MLOps capabilities: model documentation, validation, monitoring, and governance are all mandated. Sending training data to a cloud-based ML platform (SageMaker, Vertex AI) creates data sovereignty and regulatory issues. A self-hosted MLOps stack is the only compliant path for regulated financial ML.
AravaliStack includes a complete on-premise MLOps stack — experiment tracking, model registry, automated pipelines, GPU-accelerated serving, and production monitoring — all within your infrastructure. No data leaves your environment for ML workloads.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The state of depending so heavily on a single vendor's products and services that switching becomes prohibitively expensive or technically complex.
Vendor lock-in is the condition in which an organisation becomes so dependent on a particular technology vendor's products, services, APIs, or data formats that the cost and complexity of switching to an alternative becomes prohibitive — effectively removing the organisation's ability to negotiate, exit, or make independent technology decisions.
Data lock-in: Your data is stored in a proprietary format or location that makes extraction expensive. Cloud egress fees ($0.08–$0.09/GB) are the most direct form of data lock-in — the more data you have, the more it costs to leave.
API lock-in: Your applications use cloud-provider-specific APIs (AWS S3 APIs, Azure Cosmos DB APIs, GCP BigQuery APIs) rather than open standards. Migrating means rewriting every integration.
Toolchain lock-in: Your deployment pipelines, monitoring stacks, identity systems, and developer tools are all provider-specific. A migration requires rebuilding the entire operational model, not just moving workloads.
Skills lock-in: Your engineering team has deep expertise in AWS (or Azure, or GCP) but no experience with alternatives. A migration requires extensive retraining or new hires.
For Indian regulated entities, vendor lock-in carries a specific regulatory risk: if a cloud provider exits the Indian market, changes pricing dramatically, changes data residency terms, or experiences a prolonged outage, the regulated entity's ability to continue operations and maintain compliance depends entirely on that provider's commercial decisions. The RBI has explicitly identified cloud provider concentration as a systemic risk and requires entities to demonstrate viable exit strategies.
Building on open-source components — Kubernetes, PostgreSQL, Kafka, Prometheus, etc. — rather than proprietary cloud services is the primary technical strategy for avoiding lock-in. Open standards (OCI containers, S3-compatible object storage APIs, OpenTelemetry) ensure that workloads can run on any infrastructure that supports those standards.
AravaliStack is built entirely on open-source components — no proprietary APIs, no vendor-specific formats. Your workloads are portable. If you ever want to migrate, the only constraint is your own hardware — not a vendor's exit fees.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A US-origin auditing standard for technology service providers, assessing controls related to security, availability, processing integrity, confidentiality, and privacy.
SOC 2 (System and Organisation Controls 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) specifically for technology and cloud service providers. A SOC 2 report assesses whether an organisation's internal controls related to security, availability, processing integrity, confidentiality, and privacy of customer data meet the AICPA's Trust Services Criteria.
A SOC 2 Type I report is a point-in-time assessment: it evaluates whether controls are suitably designed as of a specific date. A SOC 2 Type II report covers a period of time (typically 6–12 months) and evaluates both design and operating effectiveness — demonstrating that the controls were actually functioning throughout the period.
Type II is the more meaningful certification for enterprise procurement. A Type I report says "we have the right controls in place as of audit day." A Type II report says "our controls functioned as designed for 12 months." Enterprise customers almost always require Type II.
SOC 2 is a US-origin standard and is not mandated by Indian regulators. However, Indian enterprises that sell to multinational customers, or that procure services from vendors serving global markets, frequently encounter SOC 2 requirements in enterprise sales processes. Many Indian SaaS companies obtain SOC 2 certification to unlock enterprise sales in the US and EU markets.
For Indian on-premise infrastructure deployments, SOC 2 is less directly applicable — the relevant Indian frameworks (RBI IT guidelines, SEBI cybersecurity framework, CERT-In directions) cover similar ground with India-specific requirements. ISO 27001 certification is the more relevant international standard for Indian enterprise security contexts.
AravaliStack's security architecture is aligned with SOC 2 Trust Services Criteria and ISO 27001. Enterprise security assessment documentation available under NDA from our Security Trust Centre.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
An extension of DevOps that integrates security practices throughout the software development lifecycle — shifting security left so vulnerabilities are found at code time, not deployment time.
DevSecOps (Development, Security, and Operations) extends the DevOps model by integrating security practices, testing, and governance into every stage of the software development lifecycle — rather than treating security as a final gate before deployment. The core principle is "shifting security left": moving security checks earlier in the development process, where they are cheaper and faster to fix.
In a traditional software development model, security is assessed at the end: a penetration test before a major release, a code audit before a compliance audit. This creates a fundamental economic problem: the later in the development process a security vulnerability is found, the more expensive it is to fix. A vulnerability found in a code review takes minutes to fix. The same vulnerability found in a penetration test three months later requires weeks of rework, regression testing, and re-release cycles.
In code: Static Application Security Testing (SAST) tools scan code for known vulnerability patterns as developers write. Secrets scanning prevents credentials from being committed to Git. Dependency scanning identifies known-vulnerable library versions.
In the pipeline: Container image scanning checks base images and application dependencies for CVEs before deployment. Infrastructure-as-Code security scanning identifies misconfigured policies before they reach production. Compliance-as-code checks validate that deployments meet regulatory requirements.
In production: Runtime security monitoring detects anomalous behaviour (a container attempting a syscall it has never made before; a process establishing an unexpected outbound connection). Admission controllers enforce security policies before any workload is allowed to run.
AravaliStack's developer platform includes integrated DevSecOps tooling — SAST, secrets scanning, container vulnerability scanning, IaC security checks, and runtime threat detection — all enforced automatically in the CI/CD pipeline.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A cloud computing environment operated exclusively for a single organisation — providing the flexibility and self-service of cloud computing on dedicated, controlled infrastructure.
A private cloud is a cloud computing environment operated solely for a single organisation. It provides cloud-computing capabilities — on-demand self-service, elastic scaling, resource pooling, measured service — but on infrastructure that is dedicated to and controlled by that organisation, rather than shared with other customers as in a public cloud.
A traditional data centre is characterised by manual provisioning, siloed infrastructure (dedicated servers per application), and operations-team-mediated resource allocation. Deploying a new server takes days or weeks.
A private cloud replaces this with automated, self-service resource provisioning — a developer can request a new environment through a portal and have it available in minutes, while the underlying infrastructure remains on-premise and under organisational control. The cloud model is the operational and delivery model; the location and ownership are private.
An on-premise deployment describes the physical location and ownership of hardware — it says nothing about the operational model. A private cloud is always on-premise (or in a colocation facility the organisation controls), but not all on-premise infrastructure is private cloud.
Private cloud exists on a spectrum from simple virtualisation (VMware vSphere — pooled compute, but manual provisioning) to full PaaS (AravaliStack — automated provisioning, Kubernetes orchestration, integrated services, self-service developer portals). The degree to which an on-premise environment provides cloud-like capabilities determines where it sits on this spectrum.
AravaliStack is a full-stack private cloud PaaS — delivering the complete cloud experience (self-service, elastic, automated) on hardware you own, with no public cloud dependency.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A security protocol in which both the client and the server authenticate each other's certificates before establishing a connection — unlike standard TLS where only the server authenticates.
Mutual TLS (mTLS) is an extension of the standard TLS (Transport Layer Security) protocol in which both parties in a connection — both the client and the server — present and verify X.509 certificates during the TLS handshake. This provides bidirectional authentication: not only does the client verify the server's identity, but the server also verifies the client's identity before accepting the connection.
In standard TLS (the HTTPS used by browsers), only the server presents a certificate. The browser verifies that the certificate was signed by a trusted Certificate Authority and that it matches the domain. The server authenticates no further than confirming the client can complete the TLS handshake — there is no client certificate requirement. This is appropriate for public-facing web services where any client should be able to connect.
In mTLS, the server also requires the client to present a valid certificate. The server only accepts connections from clients whose certificates are signed by a known, trusted CA. This means that even if a network is compromised, an attacker cannot communicate with services — they do not have a valid client certificate.
In a microservices architecture running on Kubernetes, hundreds of services communicate with each other continuously. Without mTLS, any pod that can reach the network can send requests to any service. With mTLS enforced by a service mesh, each service has a unique cryptographic identity (a certificate tied to its workload identity), and will only accept connections from services presenting certificates from the same trust domain. Lateral movement after an initial compromise becomes nearly impossible.
mTLS adds a small overhead to connection establishment — the additional certificate exchange adds a few milliseconds to the TLS handshake. For long-lived connections (most microservice communication), this is negligible. Connection multiplexing (HTTP/2) further reduces the impact by reusing established connections for multiple requests.
mTLS is enforced by default on all service-to-service communication in AravaliStack — no opt-out, no exceptions. Every service has a SPIFFE identity with a short-lived certificate. Unidentified traffic is rejected at the mesh layer.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
A storage architecture that manages data as objects — each with data, metadata, and a unique identifier — accessible via HTTP APIs rather than file system paths.
Object storage is a data storage architecture that manages data as discrete objects — each consisting of the data itself, a variable-length metadata dictionary, and a globally unique identifier. Objects are accessed via HTTP-based APIs (most commonly the S3 API, which has become an industry standard) rather than file system hierarchies or block device interfaces.
Block storage presents raw storage blocks to an operating system, which formats them as a file system. Used for databases, VM images, and any workload requiring direct disk access. Low latency, but not shareable across multiple hosts without special configurations.
File storage presents a shared file system accessible over a network protocol (NFS, SMB). Used for shared file access, home directories, and application data that multiple servers need to read and write simultaneously.
Object storage is accessed via HTTP APIs — PUT to store an object, GET to retrieve it, DELETE to remove it. Objects are immutable once written (updates create new versions). Massively scalable (petabytes), highly durable (data is replicated across multiple disks and nodes), and accessible from anywhere with network access.
AWS S3 is the origin of the dominant object storage API — so widely adopted that "S3-compatible" has become the default expectation for any object storage system. Open-source S3-compatible object storage (MinIO being the most widely deployed) enables organisations to run S3-API-compatible storage on their own hardware, with full compatibility with applications built for S3.
For Indian regulated entities, self-hosted object storage means that ML training datasets, document stores, backup archives, and unstructured data remain on-premise — compliant with data localisation requirements — while maintaining API compatibility with the entire ecosystem of S3-native tools.
AravaliStack includes self-hosted, S3-compatible object storage — distributed across your hardware with configurable replication. Full API compatibility with S3-native tools. No egress fees. No AWS dependency.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
Rules that govern which pods and services can communicate with each other in a Kubernetes cluster — implementing micro-segmentation at the application layer.
A Network Policy is a Kubernetes API object that specifies how pods are allowed to communicate with each other and with external network endpoints. Network policies implement micro-segmentation — fine-grained network controls that restrict traffic to only what is explicitly permitted, rather than allowing all-to-all communication within a cluster.
By default, Kubernetes allows all pods to communicate with all other pods across all namespaces — a flat network model that is convenient but deeply insecure. A single compromised application pod can attempt to connect to any other service in the cluster, potentially accessing databases, identity services, or sensitive APIs it has no legitimate reason to contact.
The first and most important network policy configuration in any production cluster is a default-deny-all policy in each namespace — blocking all ingress and egress traffic except what is explicitly permitted. Applications then declare the specific traffic they require, which is allowed. This implements the zero-trust principle of least-privilege at the network layer.
Network policies are defined at the Kubernetes API level, but they are enforced by the Container Network Interface (CNI) plugin — the software component responsible for pod networking. Not all CNI plugins enforce network policies (the basic Flannel plugin does not, for example). Production-grade CNI plugins — Calico, Cilium, WeaveNet — implement network policy enforcement at the kernel level using iptables or eBPF.
For highly regulated environments, network segmentation extends beyond the Kubernetes layer to physical network infrastructure. VLAN-based segmentation isolates different security zones at the hardware switch level — ensuring that even a Kubernetes networking bug or misconfiguration cannot allow traffic to cross security boundaries, because the physical network prevents it.
AravaliStack deploys default-deny network policies across all namespaces by default. Application teams declare their required network flows as code. A Calico/Cilium CNI enforces policies at the eBPF layer for performance and reliability.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
The practice of allocating infrastructure costs to the teams, applications, or tenants that generate them — enabling financial accountability in shared infrastructure.
Cost attribution (also called cost allocation or showback/chargeback) is the practice of measuring and allocating the cost of shared infrastructure to the specific organisational units, teams, applications, or business functions that consume it. In a shared Kubernetes platform, all workloads share compute, storage, and networking resources — cost attribution makes the consumption of each consumer visible and financially accountable.
Showback means making cost consumption visible to teams — they can see how much infrastructure they're consuming, but they are not directly invoiced for it. This is informational: it changes behaviour by creating awareness, but does not create financial transactions.
Chargeback means actually billing teams or business units for their consumption — transferring the cost from a central IT budget to the consuming team's budget. This creates strong financial incentives for efficient resource use.
For MSPs hosting multiple enterprise customers on a shared AravaliStack deployment, chargeback is a billing requirement — customers are invoiced based on their actual consumption of platform resources.
Cost attribution in Kubernetes-based platforms is typically implemented at the namespace level — pods in a namespace are attributed to the team or tenant that owns that namespace. The attribution system queries the Kubernetes API for resource requests and limits, correlates them with actual utilisation data, and applies a cost model (based on hardware acquisition cost, power, cooling, and network) to produce per-namespace cost metrics.
The most effective cost attribution model surfaces cost information at the point where decisions are made: the deployment pipeline. A pull request that increases a deployment's replica count from 3 to 6 doubles its cost — showing this impact in the PR comment, before the change is merged, changes the economic calculus for every infrastructure decision an engineering team makes.
AravaliStack includes per-namespace, per-team, and per-tenant cost attribution — with real-time dashboards, CI/CD cost impact comments, budget alerts, and MSP-ready invoicing APIs.
Request a demo of AravaliStack and see how these concepts come to life in a production platform.
AWS gives you hyperscaler capabilities at the cost of data sovereignty, vendor dependency, and unpredictable bills. AravaliStack gives you the same capabilities — on hardware you own, with zero egress fees and full regulatory compliance.
Evaluated across the dimensions that matter to Indian enterprise buyers.
| Dimension | AWS | AravaliStack |
|---|---|---|
| Data residency | Contractual only — hardware in US-controlled DCs | Physical — your hardware, your premises |
| RBI compliance | Requires complex contractual frameworks | Native — designed for RBI data localisation |
| DPDP Act 2023 | Cloud DPA required; complex processor chain | On-premise — you are sole Data Fiduciary |
| Egress fees | $0.08–$0.09 per GB | ₹0 — data moves on your own network |
| Pricing model | Variable, metered, unpredictable | Fixed CapEx + annual platform licence |
| Vendor lock-in | High — proprietary APIs, S3, Lambda, IAM | None — 100% open-source components |
| Air-gapped deployment | ✗ — requires internet for control plane | ✓ — fully air-gapped supported |
| Superscaler access | ✓ — global, instant | ~ — on your hardware; plan for capacity |
| GPU / ML workloads | SageMaker — data leaves your environment | KServe + MLflow — data stays on-prem |
| Uptime SLA | 99.99% (managed by AWS) | 99.95%+ (you manage with AravaliStack tooling) |
| Security posture | Shared responsibility model | Full control — zero trust by default |
| Kubernetes | EKS — managed but opinionated | Native Kubernetes — unmodified, portable |
| Object storage | S3 — proprietary lock-in | S3-compatible on-prem — fully portable |
| Cost transparency | Complex billing, 200+ line items | Real-time per-namespace cost attribution |
| Indian data centre | ✓ ap-south-1 (Mumbai) | ✓ Deployed in your own DC anywhere in India |
| Govt / Defence use | ✗ — foreign-controlled infrastructure | ✓ — NCIIPC-approved on-premise stack |
| Support language | English; IST hours limited | Hindi + English; IST business hours |
| Exit strategy | Expensive — egress fees + rewrites | Free — open standards, no lock-in |
AWS pricing appears cheap on day one. The maths changes at scale.
Estimates based on ap-south-1 on-demand pricing and typical enterprise hardware procurement in India. Your mileage will vary — request a custom TCO analysis.
RBI's 2018 circular on storage of payment system data explicitly requires that all payment data be stored in India. AWS ap-south-1 satisfies data residency — but not data sovereignty. AWS, as a US-incorporated entity, is subject to the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act), which compels US companies to provide stored data to US authorities even when that data is held in Indian data centres. For regulated Indian financial entities, this is not a technical nuance — it is a fundamental compliance risk that no contractual arrangement can eliminate.
Request a technical briefing and custom TCO analysis. We'll model your exact AWS spend against an AravaliStack deployment.
Azure Stack brings Azure to on-premise hardware — but you're still running Microsoft's software, paying Microsoft's licences, and locked into Microsoft's roadmap. AravaliStack is built entirely on open source. No proprietary OS. No Windows tax. No foreign software dependency.
Azure Stack HCI and AravaliStack make fundamentally different architectural bets.
| Dimension | Azure Stack HCI | AravaliStack |
|---|---|---|
| Core technology | Hyper-V hypervisor + Windows Server | Native Kubernetes — no hypervisor layer |
| Licence model | Per-core Windows Server licence | Open-source — no per-node software licence |
| Kubernetes support | AKS on Azure Stack (wrapped, opinionated) | Native upstream Kubernetes |
| Linux workloads | Supported but secondary | First-class — Linux-native stack |
| Container runtime | containerd via AKS Arc | containerd — direct, unmodified |
| Identity management | Azure AD / Entra ID dependency | Self-hosted IAM — no Microsoft dependency |
| Internet connectivity | Required for Azure Arc registration | ✓ Fully air-gapped — zero internet required |
| Software updates | Via Azure portal / Windows Update | Via GitOps — pull request reviewed updates |
| ML platform | Azure ML (requires Azure subscription) | Self-hosted — data never leaves premises |
| Object storage | Azure Blob API (proprietary) | S3-compatible API (open standard) |
| RBI compliance | Requires Azure compliance frameworks | Native on-premise — full data control |
| DPDP Act compliance | Azure DPA required | On-prem — you are sole Data Fiduciary |
| Security model | Shared with Microsoft | Zero trust — you control everything |
| Observability | Azure Monitor (calls home to Azure) | Self-hosted — all telemetry on-prem |
| Vendor dependency | High — Microsoft controls roadmap | None — open-source components |
| India data residency | Contractual via Azure India | Physical — your hardware |
| Foreign govt access risk | US CLOUD Act applies to Microsoft | Not applicable — no foreign software |
| Annual platform cost | High — Windows + Azure licences | AravaliStack platform licence only |
Azure Stack HCI is fundamentally a hypervisor platform (Hyper-V) with Azure management APIs layered on top. Kubernetes workloads run inside VMs, not natively on the hardware. This adds latency, overhead, and complexity — and means you're always one Windows licensing change or Azure Arc deprecation away from a forced migration.
Azure Arc, the hybrid management layer, requires regular connectivity to Azure endpoints for registration and policy sync. A genuinely air-gapped deployment is difficult to achieve and unsupported in standard configurations.
AravaliStack runs Kubernetes directly on Linux — no hypervisor, no VM overhead, no Windows kernel in the path. Containers run with direct hardware access for optimal performance. GPU workloads, NVMe storage, and high-throughput networking all operate at native speeds.
Every component is open-source and governed by independent foundations (CNCF, Apache, Linux Foundation). No single vendor controls the roadmap. No proprietary licence can be revoked. No foreign government has legal authority over the software you run.
Microsoft Corporation is incorporated in the United States and is subject to the US CLOUD Act. This means that even data stored on Azure Stack HCI hardware physically located in India could be subject to US government access requests directed to Microsoft. For Indian defence, government, and critical infrastructure operators, running Microsoft software on-premise does not eliminate this jurisdictional risk — it is the software that matters, not only the hardware location. AravaliStack runs no US-controlled proprietary software.
No Windows tax. No foreign software dependency. Full regulatory compliance for Indian enterprises.
VMware Tanzu is enterprise Kubernetes on top of vSphere — built for the VMware world. If you're running vSphere, Tanzu is the path of least resistance. If you want to own your stack, eliminate per-VM licence costs, and run a modern cloud-native platform without a Broadcom subscription, AravaliStack is the answer.
Broadcom's 2023 acquisition of VMware introduced sweeping pricing changes that shocked enterprise customers globally. Perpetual licences were eliminated. Subscription bundles were restructured. Many enterprises reported 3–10× price increases on renewal. Indian enterprises running VMware/Tanzu estates are actively evaluating exit strategies — and AravaliStack is the most direct migration path to an open-source, India-sovereign alternative.
| Dimension | VMware Tanzu | AravaliStack |
|---|---|---|
| Kubernetes model | Kubernetes on vSphere (TKG) — VM-based nodes | Native Kubernetes on bare metal / Linux VMs |
| Hypervisor dependency | Requires vSphere / ESXi | None — runs without hypervisor |
| Licence model | Broadcom subscription bundles | Open-source + AravaliStack platform licence |
| Pricing predictability | Changed dramatically post-Broadcom | Fixed annual platform licence |
| vSphere migration | Minimal — already on Tanzu | Guided migration path — 30–90 days |
| Security model | NSX micro-segmentation (add-on cost) | Zero trust built-in — mTLS, OPA, Vault |
| Service mesh | NSX Service Mesh (paid add-on) | Integrated — included in platform |
| Secrets management | External vault integration required | Built-in — dynamic secrets out of the box |
| GitOps | Supported via TMC | Native — GitOps is the only change mechanism |
| ML platform | Not included — separate product | Integrated MLOps stack included |
| Observability | vRealize Operations (add-on cost) | Integrated — metrics, logs, traces included |
| Air-gapped support | ✓ with offline bundles | ✓ fully air-gapped by default |
| India compliance | Validated for on-premise use | Designed specifically for Indian regulations |
| Open source | Partially — Tanzu community edition | 100% — all components open-source |
| Broadcom dependency | High — core product | ✗ — no VMware/Broadcom component |
| Foreign software risk | US-headquartered (Broadcom/VMware) | ✗ — no foreign software dependency |
| Support | Global enterprise support | India-based, IST hours, Hindi + English |
Inventory workloads, map vSphere dependencies, identify Tanzu-specific APIs to refactor
Deploy AravaliStack cluster alongside Tanzu — validate platform capabilities, migrate non-critical workloads first
Containerise remaining VM workloads, migrate stateful services with zero-downtime cutovers
Validate all workloads on AravaliStack, confirm monitoring parity, retire vSphere/Tanzu licences
Most enterprises complete the migration in 30–90 days. AravaliStack's migration tooling handles container image conversion, storage migration, and network policy translation automatically.
AravaliStack is the sovereign, open-source alternative Indian enterprises are migrating to. Request a migration assessment today.
This is the most consequential infrastructure decision an Indian bank's CTO makes. The wrong choice costs crores in compliance remediation, regulatory scrutiny, or cloud bills. Here is the complete picture — regulatory, financial, and technical.
Understanding the regulations is not optional. It is the starting point.
RBI's April 2018 circular directed all payment system operators to store entire payment data — end-to-end transaction details, including payment instructions — only in India, within six months. This applies to all entities in the payment ecosystem, including processors, aggregators, and banks.
Material technology changes — including cloud migration of core banking systems — require Board or Board Committee approval, documented risk assessments, and demonstration of business continuity capability. Cloud providers must be subject to due diligence and regular audit rights.
SEBI's circular on cloud adoption requires that critical data — trading records, investor accounts, audit trails — be stored and processed within India. Overseas processing requires prior approval. Concentration risk with a single cloud provider must be managed and disclosed.
The DPDP Act empowers the Central Government to restrict cross-border transfer of personal data. For banks processing millions of customers' personal financial data, the Data Fiduciary obligations are significantly simpler to discharge on infrastructure you directly control.
| Dimension | Public Cloud (AWS/Azure/GCP) | On-Premise (AravaliStack) |
|---|---|---|
| RBI payment data requirement | Contractual data residency only | Physical data residency — your hardware |
| US CLOUD Act exposure | Yes — US-HQ cloud providers subject to it | None — no US software dependency |
| DPDP Act Data Fiduciary | Complex — cloud provider is sub-processor | Simple — you are sole Data Fiduciary |
| RBI supervisory access | Requires cloud provider cooperation | Direct — regulator can audit your systems |
| CERT-In 6-hour reporting | Depends on cloud provider incident logs | Full control over incident investigation |
| Core banking data | Stored on foreign-controlled infrastructure | On your hardware — full sovereignty |
| Customer PII | Subject to foreign data laws | Stays in India, on your systems |
| Fraud detection ML models | Data must leave premises for cloud ML | Train and serve on-prem — no data egress |
| Cost model | Variable OpEx — unpredictable at scale | Fixed CapEx + predictable platform licence |
| Egress fees | ₹0.08/GB — significant at banking volumes | ₹0 — internal network traffic |
| Vendor negotiation leverage | Low after lock-in | High — open source, no dependency |
| Air-gapped capability | Impossible by definition | Fully supported |
| Latency (branch-to-DC) | Network round-trip to cloud region | Direct — within your WAN |
| Business continuity | Cloud provider availability-dependent | You control DR strategy entirely |
| Scale | Elastic — instant provisioning | Planned — requires capacity management |
| Developer productivity | High — rich managed services | High — AravaliStack provides same managed services |
| Security posture | Shared responsibility model | Full ownership — zero trust by default |
| Regulatory audit | Cloud compliance reports (SOC2, ISO) | Direct audit access to all systems |
Cloud is appropriate for non-core, non-regulated workloads — and Indian banks are using it effectively in these contexts:
These workloads do not involve core banking data, payment records, or personally identifiable financial information. They are appropriate candidates for cloud hosting under current RBI frameworks.
These workloads involve regulated data categories for which cloud storage either violates RBI circulars or creates unacceptable regulatory risk. They belong on-premise, on infrastructure you control.
The answer for most Indian banks is not "cloud or on-premise" — it is a governed hybrid. Core regulated workloads on-premise with AravaliStack, non-regulated workloads on cloud, unified management and security across both.
Train, deploy, and monitor credit scoring models on infrastructure you own — without sending customer financial data to a cloud provider. RBI model risk management compliant. Sub-100ms inference. Full audit trail.
Training a credit model requires bureau data, transaction history, account behaviour, and repayment records — all sensitive personal financial data. Sending this to AWS SageMaker, Azure ML, or Google Vertex AI means your customers' financial profiles exist on foreign-controlled infrastructure.
RBI's guidelines on model risk management (MRM) require that banks document model development, validation, and performance monitoring — with the ability to produce a complete model lineage for regulatory examination. Cloud-based training workflows often lack the reproducibility and audit trail MRM requires.
Models must be retrained periodically as economic conditions change. Every retraining cycle is a fresh exposure — your customers' latest financial data going to a cloud provider each time.
AravaliStack's ML platform (GPU-accelerated compute + distributed training framework) runs on your own hardware. Feature pipelines, training jobs, and model evaluation all execute within your network perimeter. Bureau data, transaction records, and customer profiles never leave your data centre.
Every training run is logged: dataset version, feature set, hyperparameters, evaluation metrics, model artefact checksum, and environment specification. The MLflow experiment registry provides the complete model lineage that RBI MRM examinations require — reproducible, tamper-evident, auditable.
Production models are served via KServe — a Kubernetes-native model serving framework. Loan origination systems, mobile apps, and internal credit tools query the inference endpoint with typical response times of 40–80ms for most gradient boosting and neural credit models.
All components run within your on-premise AravaliStack cluster. No data leaves your network at any stage.
Every experiment logged with full parameter set, dataset hash, and environment spec. Export to PDF for regulatory submission.
Shadow model deployments enable champion-challenger testing. Validation team gets read-only access to model artefacts and evaluation data.
Population Stability Index (PSI), GINI coefficient, and KS statistic tracked continuously. Automatic alerts when drift exceeds thresholds.
All model deployments, parameter changes, and data access events logged to tamper-evident audit storage. Full reproducibility guaranteed.
End-to-end data lineage from raw bureau data through feature engineering to training set. No black-box data provenance.
Pre-built report templates for RBI IT examination on model risk — covering model inventory, validation status, performance metrics, and incident history.
AravaliStack includes the complete ML infrastructure stack. Bring your models — we provide the compliant platform.
Build, deploy, and operate a fully ABDM-compliant Health Information System on sovereign infrastructure — with ABHA-linked records, FHIR-native APIs, and end-to-end encryption. No patient data on foreign servers. Ever.
The Ayushman Bharat Digital Mission (ABDM) is India's national digital health initiative, creating a unified health data ecosystem through ABHA (Ayushman Bharat Health Account) identifiers, a Health Information Exchange (HIE), and interoperability standards based on HL7 FHIR R4. Every healthcare entity — hospitals, diagnostics labs, health-tech platforms, insurance companies — that participates in ABDM must implement systems that handle ABHA-linked health records under strict data governance requirements. NHA mandates that health data remain within India and under governance frameworks that prevent unauthorised foreign access.
Federated identity with NHA's ABHA services. Patients authenticate with ABHA ID to access or share their records. Consent tokens issued per access request.
HL7 FHIR R4 server storing clinical resources — Observations, DiagnosticReports, Immunizations, Medications, Conditions. Full FHIR search and subscription support.
ABDM HIE gateway — send and receive health records from other ABDM-registered HIP/HIU entities. Encrypted end-to-end with patient consent validation.
Patient consent vault — granular permissions per data category, per recipient, per time window. Consent revocation propagates in real time to all dependent services.
De-identified data pipeline for population health analytics, disease surveillance, and clinical research — DPDP-compliant anonymisation before any aggregation.
Every data access, consent grant/revoke, and record modification logged to tamper-evident storage. Ready for NHA compliance audits and DPDP Act oversight.
ABDM-compliant. DPDP-ready. Patient data stays in India. Always.
Train and deploy AI models on classified datasets — with zero network exposure. No telemetry, no licence servers, no external dependencies of any kind. Designed for NCIIPC-designated environments, Tier-1 defence contractors, and strategic government installations.
The Indian defence ecosystem — from the three services and DRDO to Tier-1 contractors like HAL, BEL, BDL, and MDL — is increasingly integrating AI and machine learning into critical systems: autonomous platforms, ISR analytics, predictive maintenance, logistics optimisation, and signals intelligence processing. The challenge is that every commercial AI platform — AWS SageMaker, Google Vertex AI, Azure ML, and even open-source tools that phone home for updates — is fundamentally incompatible with air-gapped, classified-environment operation. AravaliStack is designed from first principles for this requirement.
Multi-GPU, multi-node distributed training for large models — computer vision, NLP, signal processing — using on-premise GPU clusters. No cloud burst required.
All trained model artefacts stored in the on-premise model registry. Versioned, signed, and access-controlled. Transfer to other facilities via encrypted physical media.
Low-latency model serving for real-time applications — target recognition, anomaly detection, predictive maintenance — on isolated inference nodes.
Full reproducibility for all training runs — dataset version, hyperparameters, environment, metrics. Audit-ready for programme office review.
Train models across multiple air-gapped facilities without centralising raw data — only model gradients exchanged over point-to-point encrypted links.
On-prem adversarial attack simulation and model hardening — test model resilience to adversarial inputs without exposing models to external parties.
Processing imagery, signals, and sensor data from intelligence, surveillance, and reconnaissance systems. Computer vision models for target detection and classification. All data, models, and inference results remain classified and isolated.
ML models trained on sensor telemetry from aircraft, ships, and vehicles to predict component failures before they occur. Training data never leaves the maintenance facility.
Research platforms for developing AI capabilities for defence applications — from materials science to autonomous systems. Multi-investigator collaboration with fine-grained access control between research teams.
NCIIPC-designated operators — power, water, telecom — deploying ML for anomaly detection in operational technology (OT) systems. Air-gapped from both internet and corporate IT networks.
Engineered for air-gapped operation from first principles. Request a classified capability briefing through secure channels.
Everything a CTO, CISO, or infrastructure architect needs to know before evaluating AravaliStack. 28 questions across general, infrastructure, deployment, security, and commercial topics.
Our solutions architects answer every serious inquiry — no sales pressure, no auto-responders.
NBFCs operate at the intersection of RBI regulatory pressure, data-intensive lending operations, and rapid digital growth. AravaliStack gives you sovereign infrastructure to run credit scoring, loan origination, collections analytics, and compliance systems — without sending customer financial data to a foreign cloud.
RBI's Scale-Based Regulation (SBR) framework creates four tiers — NBFC-BL, NBFC-ML, NBFC-UL, and NBFC-D — with progressively stricter IT governance at each tier. NBFC-UL entities now face requirements comparable to scheduled commercial banks: Board-level IT strategy committee, IT risk framework, BCP/DR requirements, and a cyber security policy aligned with RBI guidelines. Cloud infrastructure choices made today will be scrutinised in your next regulatory examination. The safest posture is on-premise infrastructure under your direct control.
| Regulation | Requirement | AravaliStack Capability |
|---|---|---|
| RBI SBR — NBFC-UL | Board IT Committee; IT governance framework; cyber security policy mandatory | GitOps audit trail for all changes; RBAC with Board-level access review; zero-trust security baseline |
| RBI Fair Practices Code | Transparent loan pricing; audit trail for credit decisions | Immutable audit log for all credit model decisions; model lineage for explainability |
| RBI Data Localisation | Customer financial data stored in India | On-premise deployment — data never leaves your facility |
| DPDP Act 2023 | Consent for personal data processing; right to erasure | Consent management APIs; data deletion workflows; Data Principal rights portal |
| CERSAI Integration | Security interest registration; real-time charge verification | Secure API gateway for CERSAI with full TLS and audit logging |
| PMLA / AML | Transaction monitoring; STR reporting to FIU-IND | On-premise AML model serving; audit-ready STR workflow |
| KYC / CKYC | Digital KYC; CKYC repository push/pull | Secure CKYC API integration; biometric data processed on-premise |
| CERT-In 2022 | 6-hour incident reporting; 180-day log retention | Automated incident detection; tamper-evident log archive |
Train bureau-based, behavioural, and alternative-data credit models entirely on-premise. Sub-100ms inference for real-time loan origination. Full RBI MRM audit trail.
ML-driven collections prioritisation, promise-to-pay prediction, and channel optimisation. Models trained on your repayment history — no data shared with cloud ML platforms.
Real-time application fraud, identity fraud, and bust-out fraud detection. Graph neural network models for first-party fraud rings. Inference at origination speed.
Cloud-native LOS on AravaliStack — API-first, integrated with Account Aggregator (AA) framework, CKYC, and bureau APIs. All data stays on-premise.
Secure data exchange and risk-sharing infrastructure for co-lending arrangements — with per-partner namespace isolation and bilateral audit trails.
RBI digital lending guidelines compliant: disbursement to bank accounts only, KFS generation, loan account statement APIs — all auditable and on-premise.
From NBFC-BL digital lenders to NBFC-UL systemically important entities — AravaliStack scales with your regulatory tier.
India's insurance sector is undergoing its fastest digital transformation — Bima Sugam, ABHA health data integration, usage-based motor insurance, and real-time claims processing. Every insurer building digital infrastructure in 2026 faces the same challenge: IRDAI requires data sovereignty, but modern insurance needs cloud-scale ML. AravaliStack is how you get both.
IRDAI's Information and Cyber Security Guidelines (2023) mandate: a Board-approved IT and cyber security policy, a CISO reporting to the Board, annual cyber security audits by CERT-In empanelled auditors, and a formal incident reporting mechanism. Data relating to Indian policyholders must be maintained within India. Third-party cloud providers used for critical insurance operations must be subject to due diligence and contractual security requirements — a process that is substantially simpler when your infrastructure is on-premise and under your direct control.
| Regulation | Requirement | AravaliStack Capability |
|---|---|---|
| IRDAI IT & Cyber Security Guidelines 2023 | CISO mandate; Board-level IT policy; annual cyber audit | Zero-trust security baseline; RBAC governance; audit-ready compliance reports |
| IRDAI Data Localisation | Policyholder data maintained within India | On-premise — physical data residency on your hardware |
| IRDAI Outsourcing Guidelines | IT outsourcing subject to due diligence | Self-hosted — no IT function outsourced to foreign cloud providers |
| Bima Sugam Integration | API-based policy issuance, renewal, and claims via national marketplace | Secure API gateway for Bima Sugam; policy and claims data on-prem |
| ABHA / Health Data | Health data governance per NHA/ABDM framework | FHIR R4 health data platform; patient consent management; on-prem storage |
| Motor Insurance / IIB | Accident data reporting to IIB; VAHAN integration | Secure integration APIs; data stays on-prem |
| DPDP Act 2023 | Consent for personal data; sensitive health data protection | Consent management platform; health data with customer-specific encryption keys |
| CERT-In 2022 | Incident reporting within 6 hours | Automated threat detection and incident notification pipeline |
Train mortality, morbidity, and loss models on your complete historical claims data — without sending policyholders' health and lifestyle data to a cloud ML platform. Reproducible experiments with full model governance.
Real-time and batch fraud scoring across motor, health, and life claims. Network analysis for organised fraud rings. Survival analysis for claim timing anomalies. Trained on your claims history.
ABHA-linked health history integration for medically underwritten policies. Chronic disease risk models on de-identified population data. Pre-authorisation decisioning under 200ms.
Telematics data processing and driver behaviour scoring on-prem. Trip data never leaves your infrastructure. Dynamic premium models updated daily from fresh telematics data.
Document intelligence (OCR + NLP) for claims document extraction. Medical bill scrutiny. Repair cost estimation via computer vision. Straight-through processing for low-complexity claims.
Automated generation of IRDAI returns, IIB reports, and IRDA annual statements from live data. Reconciliation workflows. Audit-ready report lineage — all on-premise.
Bima Sugam requires all insurers to expose standardised APIs for policy issuance, renewal, endorsement, and claims initiation. AravaliStack provides the complete on-premise API infrastructure:
From life and health to motor and general — AravaliStack handles the full insurance technology stack on your hardware.
Public Sector Banks operate under the most demanding combination of regulatory scrutiny, technology modernisation pressure, and data sovereignty requirements in India's financial system. AravaliStack is the on-premise PaaS platform built for PSB scale, security posture, and compliance — from Core Banking modernisation to real-time fraud analytics and RBI supervisory access.
Public Sector Banks face infrastructure requirements more stringent than private sector banks. First, as government-owned entities, PSBs are subject to CAG audits requiring direct access to IT systems — incompatible with third-party cloud. Second, MeitY's guidelines require sensitive government data use government-approved infrastructure (MeghRaj/NIC Cloud) or on-premise deployments. Third, NPCI and RBI jointly supervise PSBs' payment infrastructure with supervisory access requirements that foreign-controlled cloud providers cannot guarantee. AravaliStack is designed for exactly this environment.
| Regulation | Requirement | AravaliStack Capability |
|---|---|---|
| RBI IT Framework for Banks | IT strategy; risk management; BCP/DR; change management | GitOps change management with full PR audit trail; integrated BCP/DR tooling |
| RBI Supervisory Access | RBI examiners must have direct, unimpeded access to bank systems | On-premise deployment — no third party in the access chain |
| CAG Audit Requirements | CAG has audit rights over all PSB IT systems and data | Direct infrastructure access for CAG teams; immutable audit logs |
| MeitY Cloud Policy | Sensitive government data on MeghRaj or on-premise | AravaliStack on-premise satisfies MeitY data classification requirements |
| NPCI Systems | UPI, IMPS, NACH, BBPS — real-time settlement infrastructure | On-premise high-availability cluster for NPCI-integrated payment systems |
| RBI DPSS Guidelines | Payment system security; data localisation; audit trails | Zero-trust payment infrastructure; tamper-evident transaction logs |
| CERT-In / IT Act | Incident reporting; 180-day log retention | Automated CERT-In reporting workflows; long-retention log archive |
| CVC Guidelines | Vigilance systems must be independently auditable | Isolated namespace for vigilance systems with independent access controls |
API modernisation layer over legacy CBS (Finacle, BaNCS, Flexcube) — exposing microservices APIs without replacing core systems. Zero-downtime strangler-fig migration pattern.
UPI, IMPS, NACH, and BBPS processing. Sub-50ms transaction processing. 99.999% availability with active-active multi-DC. All NPCI transaction data stays on-premise.
Real-time transaction monitoring at PSB scale. Graph analytics for money mule detection. FIU-IND STR reporting integration. Models trained on the bank's own transaction history.
ML-based early warning system for loan stress — identifying potential NPAs before they occur. Sector concentration risk monitoring. RBI regulatory reporting automation.
Automated PSL tracking, sub-target monitoring, and RIDF obligation calculation. Real-time Board reporting. Integration with PM-Kisan, MUDRA, and government scheme portals.
Zero-trust architecture for internet banking, mobile banking, and API banking. Bot detection, session anomaly detection, and real-time transaction fraud scoring.
Full AravaliStack cluster — all production workloads, core banking integration, and payment systems. Primary site for all regulated data.
Hot standby — RPO <15 min, RTO <30 min. Automated failover for all critical payment systems with continuous replication.
Edge nodes for regional agri loan analytics, regional language interfaces, and local compliance workloads.
Zero-trust connectivity for 1,000+ branches — CBS access, document management, and queue management systems.
AravaliStack can be deployed on NIC Cloud / MeghRaj infrastructure, satisfying MeitY's cloud policy for government entities while delivering full PaaS capabilities. Alternatively, AravaliStack runs on the bank's own data centre hardware with a hybrid integration to NIC Cloud for non-sensitive workloads — satisfying both MeitY and RBI requirements simultaneously.
PSBs run India's financial backbone. AravaliStack ensures that backbone is sovereign, compliant, and modern.
HAL, BEL, BDL, MDL, BEML, DRDO, ISRO, NTPC, ONGC — India's strategic enterprises operate at the intersection of national security requirements, NCIIPC mandates, and the urgent need to modernise technology infrastructure. AravaliStack is purpose-built for this environment: fully air-gapped, zero foreign software dependency, certified for classified-adjacent deployments.
India's defence and strategic PSUs must modernise rapidly to remain operationally effective — but commercial cloud infrastructure is unusable for sensitive workloads. The US CLOUD Act makes AWS, Azure, and GCP unsuitable: US-headquartered companies can be compelled to provide data to US authorities even from Indian data centres. VMware is now Broadcom — a foreign-controlled entity. Even open-source tools that phone home for updates create unacceptable exposure in classified-adjacent environments. AravaliStack solves this: cloud-native PaaS capabilities, on your hardware, with zero external dependencies. Built in India. Governed in India.
| Regulation | Requirement | AravaliStack Capability |
|---|---|---|
| NCIIPC Guidelines | CII protection; mandatory incident reporting; security audits | Air-gapped deployment; zero telemetry; NCIIPC-aligned security controls |
| MeitY Cloud Policy | Government data on government-approved infrastructure | On-premise or NIC Cloud deployment — satisfies MeitY data classification |
| DRDO Security Policy | Classified research data must not leave DRDO premises | Air-gapped, on-premise — physically isolated from all external networks |
| IT Act 2000 / CERT-In | Incident reporting; vulnerability assessment | Automated incident detection; on-premise CERT-In reporting workflows |
| MoD IT Security Policy | Defence IT infrastructure per MoD security standards | Configurable to MoD IT security baseline; TPM 2.0 node attestation |
| DAP 2020 (Defence Acquisition) | Indigenous software preference; technology transfer terms | 100% open-source components; built and supported in India by TechRajendra® |
Predictive maintenance for aircraft production lines. Digital twin infrastructure for LCA Tejas and ALH Dhruv programmes. CAD/CAM data management with classification-tiered access controls.
Electronic warfare system simulation. Radar signal processing data management. Production quality control ML. Secure supply chain analytics for ITAR-restricted components.
Multi-lab research data management with inter-lab isolation. HPC workloads for simulation and modelling. Classified experiment data in air-gapped ML training clusters.
Satellite data processing and archival. Mission simulation compute. Ground station data management with air-gapped operation during launch operations.
Shipbuilding and vehicle manufacturing MES integration. Logistics and supply chain analytics. Quality management systems. Production planning optimisation.
Critical infrastructure OT/IT integration — SCADA data processing, anomaly detection, and predictive maintenance. Air-gapped from both internet and enterprise IT networks.
Defence PSUs often process data at multiple classification levels — Unclassified, Restricted, Confidential, Secret — on shared hardware while maintaining strict separation. AravaliStack supports this through namespace-level isolation with default-deny network policies per classification tier, dedicated node pools with hardware-level taint enforcement so high-security workloads never share CPUs with lower-security ones, and per-tier encryption keys stored in isolated Vault paths with no cross-tier key access possible.
No foreign software. No cloud dependency. No compromise.
Finacle is the core banking system powering over 100 Indian banks. AravaliStack is the sovereign cloud platform running alongside it — providing the API modernisation layer, ML infrastructure, and cloud-native developer platform that Finacle itself does not offer. Together they form the complete modern banking technology stack.
Finacle excels at what it was designed to do: run core banking operations with the reliability and compliance Indian banks require. What it does not provide is a cloud-native platform for the surrounding ecosystem — the ML models, the API gateways, the developer tooling, the observability stack, the DevOps platform. Banks are building this surrounding layer on AravaliStack, with Finacle as the authoritative source of record for customer accounts, transactions, and product configurations.
AravaliStack wraps and extends Finacle — Finacle handles CBS; AravaliStack handles everything around it. All on-premise.
AravaliStack's API gateway exposes Finacle's REST and OFS APIs to digital channels with OAuth 2.0, rate limiting, API versioning, and per-client usage analytics.
Finacle transaction events published to AravaliStack's streaming platform — consumed by fraud detection, ledger analytics, and regulatory reporting in real time.
EOD and intra-day extracts from Finacle loaded into AravaliStack's data platform for ML training, analytics, and RBI return generation.
New microservices on AravaliStack call Finacle for authoritative account data while owning new product capabilities progressively — no big-bang CBS replacement.
| Finacle Version | Integration Method | API Protocol | Notes |
|---|---|---|---|
| Finacle 11.x (Universal Banking) | REST APIs + Kafka event streaming | REST/JSON, Avro | Recommended — full API coverage |
| Finacle 10.x | MQ-based integration + batch | MQ/XML, CSV | Supported — adapter layer provided |
| Finacle CBS (legacy) | Database-level batch extract | JDBC/CSV | Supported — read-only integration |
Extend your Finacle investment with sovereign cloud-native infrastructure. No migration risk. No cloud dependency.
Temenos T24 (now Temenos Transact) is deployed at private banks, co-operative banks, and microfinance institutions across India. AravaliStack provides the sovereign cloud platform layer — API management, ML infrastructure, observability, and developer tooling — that surrounds and extends Temenos for modern digital banking.
Temenos T24/Transact is a proven CBS for Indian private and cooperative banks. As digital banking expectations escalate — UPI deep links, AA framework, BNPL, real-time collections — banks find that T24 alone cannot support the full digital ecosystem. The typical response is to add cloud-based middleware: AWS API Gateway, Azure Functions, GCP BigQuery. This creates data sovereignty exposure and RBI compliance complexity. AravaliStack eliminates both by providing the same capabilities on-premise, alongside Temenos, on your own hardware.
T24 OFS commands and REST APIs proxied through AravaliStack's API gateway. OAuth 2.0, per-client rate limits, API versioning, and real-time usage analytics — transparent to T24.
T24 events published to AravaliStack's streaming platform via MQ adapter. Downstream consumers: fraud detection, real-time dashboards, and regulatory reporting engines.
Nightly and intra-day T24 data extracts into AravaliStack's data platform. ML model training, BI, and RBI return generation from T24 data — all on-premise.
T24 customer identities federated with AravaliStack's IAM for digital banking applications. Single sign-on across T24-backed services and new microservices.
T24 application metrics, database performance, and API response times in AravaliStack's observability stack. Unified alerting across T24 and surrounding platform.
New capabilities (AA integration, BNPL, co-lending) deployed as microservices on AravaliStack — consuming T24 APIs for account data, publishing results back via MQ.
AravaliStack API gateway handles UPI transaction routing, balance checks, and mandate management — consuming T24 account APIs for settlement.
ReBIT-compliant FIP/FIU endpoints on AravaliStack consuming T24 account data — with DNBI encryption and consent validation.
AravaliStack handles NACH presentation and return processing — with T24 providing account debit/credit execution.
Automated PSL data extraction from T24, classification, and NABARD/RBI submission — on AravaliStack's data platform.
KYC data from T24 enriched and submitted to CKYC registry via AravaliStack's secure API gateway with full audit trail.
ECL computation and Ind AS 109 reporting from T24 loan book data — ML-based PD/LGD models trained on T24 history.
Urban Cooperative Banks (UCBs) and Microfinance Institutions (MFIs) using Temenos face the same data sovereignty requirements as larger banks — but with smaller IT teams and tighter budgets. AravaliStack's 3-node compact deployment provides full platform capability for smaller T24 deployments, deployable in under 5 days and manageable by a 2-person IT team.
T24 as your CBS. AravaliStack as your platform. All on-premise. All yours.
SAP runs the operational backbone of India's largest enterprises — PSUs, defence contractors, manufacturing conglomerates, and pharmaceutical companies. AravaliStack provides the sovereign cloud platform on which SAP S/4HANA runs, and the surrounding ecosystem (ML, API management, data platform, DevOps) that SAP BTP provides in the cloud but cannot offer on-premise with full data sovereignty.
SAP is aggressively pushing customers toward RISE with SAP — cloud-hosted S/4HANA on hyperscaler infrastructure. For Indian PSUs, defence contractors, regulated financial enterprises, and government-linked manufacturing companies, RISE with SAP creates an unacceptable data sovereignty problem: your ERP data — procurement records, financial ledgers, HR records, manufacturing data — moves to a foreign-controlled cloud. AravaliStack is the on-premise platform on which SAP S/4HANA runs with full sovereignty, paired with AravaliStack's own platform services as an on-premise alternative to SAP BTP.
AravaliStack provides the Kubernetes-based infrastructure on which SAP S/4HANA (containerised or VM-based) runs on-premise. AravaliStack handles storage, networking, security, observability, and backup while SAP handles the application.
AravaliStack provides integration, extension, and analytics capabilities that SAP BTP offers — but on-premise. Custom extensions, event processing, data analytics, and ML without BTP's cloud dependency.
SAP APIs (OData, RFC, BAPI, iDoc) exposed via AravaliStack's API gateway to non-SAP systems — with authentication, rate limiting, and versioning. Replaces SAP API Management (cloud-only).
SAP business events (purchase orders, goods movements, financial postings) streamed via AravaliStack's event platform. Downstream consumers: ML models, reporting, integration systems.
S/4HANA data extracted to AravaliStack's data platform for ML. Demand forecasting, supplier risk scoring, procurement fraud detection — trained on your SAP data on-premise.
Integration flows between SAP and non-SAP systems on AravaliStack — replacing SAP Integration Suite (cloud). iDoc processing, EDI/B2B messaging, API-to-BAPI adapters.
HANA data replicated to AravaliStack's analytical data store. BI dashboards, management reporting, and operational analytics — without SAP Analytics Cloud.
SAP user identities federated with AravaliStack's IAM. Single sign-on across SAP and non-SAP systems. SAP roles mapped to Kubernetes RBAC for hybrid access control.
S/4HANA for procurement, HR, and finance on AravaliStack on-premise. Custom MES microservices on AravaliStack consuming SAP production orders. Supplier portal API gateway. Defence-classified procurement data never on cloud.
S/4HANA with SAP QM for GMP compliance on AravaliStack. Batch traceability data sovereign — critical for USFDA and EMA audit requirements. ML demand forecasting from SAP sales data on-premise.
S/4HANA for plant maintenance, procurement, and finance. AravaliStack OT/IT integration layer consuming SCADA data alongside SAP PM data. Predictive maintenance ML trained on SAP order history — all on-premise.
S/4HANA for upstream and downstream operations. AravaliStack data platform for reservoir analytics, production optimisation ML, and supply chain intelligence — all from SAP data, all on-premise.
AravaliStack is the sovereign on-premise platform for SAP S/4HANA — and the on-prem alternative to SAP BTP.