Home Services Work Products Infrastructure Contact

GRAVAXIS

Software Infrastructure Solutions

We design, build and run the infrastructure your product depends on, and the software that sits on top of it.

Build

Cloud architecture, provisioning and delivery pipelines. Environments defined as code, so every rebuild is identical to the last.

Run

Managed application and database hosting. Patching, backups, monitoring and capacity are our responsibility, not your ticket queue.

Secure

Hardened baselines, least-privilege access and audit-ready logging. Security decisions written down, not assumed.

Host

Physical servers in commercial data centre facilities. Racked, powered, networked, and remote hands when a person has to be there.

Boring infrastructure.
On purpose.

Interesting infrastructure is infrastructure that surprises you at 3am. We build the other kind. Every environment is described in code and rebuilt from that code, so nothing exists that nobody can account for. Every deployment goes through a pipeline that can be rolled back. Every alert routes to a named person with a runbook in front of them.

gravaxis.operating-principles
# how every engagement is built
infrastructure: defined as code
access_model : least privilege
deployment  : pipeline with rollback
alerting    : named owner + runbook
handover    : code + documentation
ownership   : yours, throughout
AWS Primary public cloud platform
Chennai Engineering and operations base
SLA Availability targets set per engagement, in writing
ACY-2772 Registered LLP · Ministry of Corporate Affairs, India

We build platforms,
and we run them.

For clients: Claimstant, a claim-linked funding platform coordinating insurers, garages and vehicle owners through one controlled transaction, and ThrowdownLive, a livestreaming platform for going live and watching. For ourselves: Ledgerwing, GST billing with an append-only audit trail, and Stagehand AI, a self-hosted AI assistant that answers WhatsApp enquiries and waits for approval on anything that matters. All four sit on exactly the stack we design for everyone else, so the practices we recommend on this site are the ones we depend on ourselves.

Tell us what you're running.

Our Services

Five service lines. Cloud infrastructure, managed hosting, security, physical hardware, and the software that runs on all of it. Take one, or take the stack.

01: Cloud

Cloud Infrastructure
& DevOps

We design and build cloud environments on AWS. Infrastructure is defined as code, versioned, and reproducible. Deployments run through pipelines with a rollback path, not through a console at midnight.

  • Architecture design, migration planning and landing-zone setup on AWS
  • Infrastructure as code: every environment provisioned from a repository, never by hand
  • CI/CD pipelines with automated testing, staged promotion and one-step rollback
  • Containerised deployment, with orchestration where the workload benefits from it
  • Cost control: resource tagging, budget alerting and right-sizing reviews on a fixed cadence
02: Hosting

Managed Hosting
& Databases

Your application and your data, run by us. Patching, backups, monitoring and capacity planning are our responsibility, not a ticket you raise. Backups that have never been restored are not backups, so restore is part of the procedure.

  • Managed application hosting: provisioning, patching and operating-system lifecycle
  • Relational and non-relational database administration, tuning and version upgrades
  • Automated backups with a stated retention period and a documented restore procedure
  • High-availability configurations where the engine and the budget support them
  • Monitoring, alerting and escalation measured against agreed response targets
03: Security

Security &
Compliance

Security is a build decision, not a layer added afterwards. Environments start closed and are opened deliberately. We harden baselines, enforce least-privilege access, encrypt in transit and at rest, and keep the logs an auditor will eventually ask for.

  • Hardened server and network baselines, applied identically across every environment
  • Identity and access management: least privilege, role separation, enforced multi-factor authentication
  • Encryption in transit and at rest, with managed key storage and rotation
  • Centralised, tamper-evident audit logging with retention aligned to your obligations
  • Vulnerability scanning, an agreed patch cadence, and documented incident response
04: Hardware

Hardware Hosting
& Colocation

Not every workload belongs in a public cloud. Licensing terms, latency, data residency and steady-state cost all argue for owning the metal. We specify, place, cable and look after physical servers in commercial data centre facilities.

  • Rack space, power and cross-connects arranged in carrier-neutral commercial facilities
  • Dedicated bare-metal servers: specification, procurement guidance, build and burn-in
  • Remote hands for reboots, media and drive swaps, recabling and physical diagnostics
  • Private connectivity between colocated hardware and your cloud environments
  • Hardware lifecycle management: health monitoring, spares, firmware and planned replacement
05: Product

SaaS &
Product Engineering

We build software products end to end: discovery, architecture, build, launch, and the operations that follow. Because we also run the infrastructure underneath, there is no handover gap: the people who wrote the application are the people responsible for keeping it up. We do this for our own products, and we do it for clients.

  • Discovery and scoping: turning a business requirement into a buildable specification
  • Application architecture, data modelling, API design and integration planning
  • Full build: web application, admin tooling, authentication, billing and third-party integrations
  • Launch engineering: environments, deployment pipelines, monitoring, backups and rollback
  • Ongoing operation: the product runs on infrastructure we manage, under a single point of contact

Not sure which of these you need?

Our Work

What we build for other people. Published with each client's agreement, which is why there are two case studies here and not ten.

Indexed 02 / 02
01: Fintech / Insurance
Controlled Pilot Designed & Built by Gravaxis
Claimstant

Claimstant

Claim-linked funding infrastructure for commercial-vehicle insurance.

An approved insurance claim does not put a truck back on the road: the payout arrives weeks after the repair needs to start. Claimstant coordinates that gap as a single controlled transaction across the vehicle owner, the garage and the surveyor. We designed and built the platform, and we run the infrastructure underneath it.

Client
Claimstant, claimstant.com
Sector
Motor insurance · commercial vehicle finance
Engagement
Product engineering: architecture, build and operation
Status
Moving into controlled pilot deployment
claimstant.com
The Claimstant home page: a headline offering early funding against an own-damage motor insurance claim, above four entry points for starting a request, tracking one, finding a garage, and total-loss settlement funding
The Claimstant How It Works page, setting out the process in numbered steps from subscribing a vehicle through raising a funding request, verification, service charge, garage co-availing and surveyor validation
One transaction, seven controlled states Intake Verification Approval Funding Insurer Submission Payout Settlement

Money that arrives
after it was needed

A commercial vehicle can sit idle even after its own-damage claim has been approved, because the settlement lands weeks later. The owner loses working days, the garage will not start without cover, and the fleet absorbs the downtime. The gap is not a payments problem: it is a coordination problem between four parties who do not share a system.

A transaction, not
a set of forms

Two funding products on one platform: funding against a vehicle under repair, and funding to close hypothecation where a vehicle is written off. Each moves through the same controlled transaction, so operations, verification and settlement are one system rather than three.

  • A state machine, not status flags, every transaction holds one state, every state has rules, and every transition is controlled
  • Built around the parties, not the payment, vehicle owners, repair garages and surveyors each act on the same case from their own view of it
  • Funding shaped to the claim, advance against interim approval, balance after final approval, or a single complete disbursal
  • Verification before funding, claim details are checked against the garage, the surveyor and official vehicle records before anything is offered
  • A transaction that can be reconstructed, material actions and state transitions are recorded as they happen
  • Total loss handled as its own path, hypothecation closure and the documentation insurers require to complete a settlement

Built to be audited

Money moving between four parties against a claim that an insurer has yet to settle is not a CRUD problem. It is judged on what it can prove afterwards, and that changes how you build: the rules live in the transaction rather than in the screens, and the tests exercise the transitions rather than the forms.

  • State transitions validated on the server, so a case cannot be advanced by editing what the interface shows
  • Permissions enforced behind the API rather than by hiding controls in the interface
  • An automated test suite written against the transaction rules, not the pages
  • The same team that designed the transaction runs the infrastructure it executes on

What is shown here: only Claimstant's public site and brand. Their internal workspaces are not published on this site, and no claim, vehicle or customer record appears anywhere on it.

For the avoidance of doubt: Claimstant is not an insurer and not a lender, that is their own published position. Gravaxis built the software that coordinates the transaction; the financial service itself is the client's, and is subject to their eligibility and verification rules.

Four parties, one
shared transaction

The reason this is infrastructure rather than an app: each party sees the same case from a different position, and the transaction has to stay consistent across all of them.

Vehicle owners

Reduce downtime and access eligible claim-linked funding while the claim is still being settled.

Repairers & garages

Get repair work moving without waiting indefinitely for the insurance settlement to arrive.

Surveyors

Review and validate the survey report the funding decision is based on.

Funding partners

Work from a structured, verified claim-linked transaction rather than a pile of documents.

02: Media / Streaming
Early Access Designed & Built by Gravaxis
THROWDOWNLIVE

ThrowdownLive

A livestreaming platform built end to end.

Throwdown Media runs ThrowdownLive as its own product: anyone can watch, and anyone can broadcast. Create an account and you get a channel, a stream key and a chat room, point standard streaming software at it and go live. Gravaxis designed and built the platform, and runs the infrastructure it streams on.

Client
Throwdown Media LLP, throwdown.tv
Sector
Media & entertainment · live streaming
Engagement
Product engineering: platform build and operation
Status
Early access
throwdown.tv
The ThrowdownLive home page: a live channel featured at the top, an also-live row beneath it, and a full channel directory below that
A ThrowdownLive channel watch page, showing the live video, a connected chat panel with follow and gift actions, and the channel's about section

Go live,
or just watch.

The platform covers the whole path from broadcaster to viewer, not just the video player in the middle.

  • Broadcast from OBS or any standard streaming software, no proprietary tooling required
  • A dedicated page per channel, each with its own chat and follower count
  • Discovery by category, plus search across every channel
  • Live chat and viewer presence on every stream
  • Following and gifting, so a viewer can support a channel directly
  • Legal, support and account pages built out from day one, not bolted on later

What is shown here: only ThrowdownLive's public pages. Nothing behind sign-in appears anywhere on this site.

On status: ThrowdownLive is in early access. What is described here is what the platform does today, not a roadmap or a projection.

We build it,
then we run it.

Product engineering and infrastructure in one engagement, whether that is a regulated-adjacent fintech transaction or a live-video platform. The same team that designs the system is responsible when it is under load.

Our Products

Gravaxis does not only build software for other people. We build and operate our own, on the same infrastructure we design for clients. This is what is publicly available today.

Indexed 02 / 02
01: Flagship
Live GST Compliance

Ledgerwing

GST billing and back office for Indian businesses.

Compliant Indian invoicing with the rest of the job attached: the people you pay, the rooms and gear you book, the catalogue you own. One workspace, one ledger, one audit trail. Built, hosted and operated by Gravaxis.

Status
Live: 14-day free trial, no card required
Category
Billing and back-office SaaS
Built & Operated By
Gravaxis Infrastructure LLP
Serves
Media, retail, wholesale, rentals, import/export and professional services
ledgerwingapp.com
Ledgerwing invoice register showing GST tax invoices with intra-state, inter-state and export supply types, multi-currency totals, and payment status
Ledgerwing dashboard showing outstanding receivables, input tax credit and a recent invoice list

Compliance software is
an infrastructure problem.

A tax invoice has to still say what it said when it was issued, years later, under audit. That is not an application feature, it is a durability guarantee, and it is the same discipline we bring to client infrastructure. Ledgerwing is where we prove it on our own time.

  • GST invoices with CGST/SGST or IGST decided from the place of supply, HSN/SAC per line, and gapless numbering per financial year
  • An append-only, hash-chained audit trail: database triggers refuse updates and deletes, so the record stands even against direct SQL
  • Multi-currency invoicing with the exchange rate stored on the document, while the ledger and GST stay in rupees
  • Payment links with verified webhooks, so an invoice settles itself without an approval step
  • Invoice register, HSN/SAC summary and a GSTR-1-shaped B2B register, exportable for any date range
  • Per-workspace isolation, branding, and separate payment and mail credentials
02: AI Assistant
Early Access Self-Hosted AI

Stagehand

Your AI manager on WhatsApp.

Stagehand answers customer enquiries on WhatsApp from the business's own price list, and books them into a calendar. It runs on the business's own PC or server rather than in the cloud, connects to a choice of AI providers including options where no conversation text leaves the machine, and every price, discount, booking, cancellation or refund can be set to wait for a person before anything is sent. Built for creative and event businesses: recording studios, artists, venues, photographers and producers who take enquiries over WhatsApp at all hours.

Status
Early access: by request, not yet self-serve
Category
Self-hosted WhatsApp AI assistant
Built By
Gravaxis Infrastructure LLP
Serves
Recording studios, artists, managers, producers, DJs, venues, photographers and videographers
stagehandai.gravaxis.in
The Stagehand inbox: a customer has asked the price of a three-hour recording session, and the assistant's drafted reply is waiting as a needs-approval card with Approve, Edit and approve, and Reject buttons
The Stagehand dashboard showing WhatsApp connected, the assistant live in Approval mode, waiting approvals and escalations, and today's and tomorrow's bookings

The AI proposes.
You decide.

An AI assistant that can quote a wrong price or make a booking nobody agreed to is worse than no assistant. Stagehand is built around control: approvals, price checks and limits are enforced by the software, not left to the AI's judgement, which is the same discipline behind every service on this site.

  • Every reply checked against the business's own price list before it is sent
  • Approvals per action: prices, discounts, bookings, cancellations, refunds and more can each be set to auto-send, ask first, or never
  • Escalation to a person on chosen words and phrases, or whenever the assistant is unsure
  • Runs as a self-hosted service on the business's own Windows or Linux machine, not a shared cloud tenant
  • A choice of AI providers, including options where no conversation text leaves the machine
  • Shared inbox, calendar, CRM and audit log in one product, not five integrations bolted together

Stagehand connects to WhatsApp as a linked device, the same way WhatsApp Web does, not through the official WhatsApp Business API. Full details and the risks are published on the product's own site.

More is in
development.

There is more in build beyond these two. We are not going to name it here, put dates on it, or open a waitlist for it. Our rule is the same one we apply to client work: nothing is described publicly until it is finished enough to use.

Policy 01

Released, not announced

A product appears on this page when it is running in production and available to use. We don't publish roadmaps, feature lists or launch dates for work that isn't done.

Policy 02

We run what we build

Our products sit on the same infrastructure we design and operate for clients. What we learn keeping our own software up goes straight back into the services on this site.

Policy 03

Ask anyway

If you're looking for something we haven't released, that conversation usually starts a project rather than a product, and we do that too. Either way, it's worth asking.

We build these
for clients too.

The same practice that produces our own software is available as a service. Discovery, architecture, build, launch, and then we keep it running, because we operate the infrastructure underneath it as well. One team writes the application and one team is responsible when it goes down. They are the same team.

The Infrastructure

What we build on, where we run it, and how we keep it running. If you are evaluating us technically, this is the page to read.

AWS Primary Infrastructure as Code Colocation Default Deny

The stack we build on

We are cloud-first and AWS-primary. Where a workload argues for dedicated hardware, we build there instead, or across both. The pattern does not change with the venue: infrastructure defined as code, deployed through pipelines, observable from the first day rather than the first outage.

  • Primary cloud: AWS. Compute, storage, networking, managed data services and identity.
  • Hybrid: designs spanning public cloud and dedicated hardware where the workload requires it.
  • Provisioning: infrastructure as code. Every environment reproducible from a repository, reviewed like application code.
  • Delivery: CI/CD pipelines with automated testing, promotion between environments, and rollback that has been rehearsed.
  • Runtime: containerised workloads with orchestration where it earns its keep, alongside conventional virtual machines where that is the better fit.
  • Observability: metrics, logs and traces in one place, with alerts routed to a person rather than to a mailbox.

From shared tenancy
to your own rack

Hosting is a spectrum, not a binary. At one end, managed instances in a public cloud you never see. At the other, hardware you bought, in a rack, in a building with a generator behind it. We operate across the whole range, and we will tell you plainly where a given workload belongs, including when the answer is "not with us".

Managed cloud

You get an application environment. We own patching, backups, scaling and monitoring.

Dedicated servers

Single-tenant bare metal for predictable performance, per-core licensing, or workloads that dislike noisy neighbours.

Colocation

Your hardware. Rack space and power we arrange, connectivity we manage, remote hands when a person has to be at the machine.

Hybrid

Colocated hardware carrying the steady-state baseline, public cloud absorbing burst and disaster recovery. One operations model across both.

What we require
of a facility

This is what we specify when placing hardware. It is a requirements list, not a description of a building Gravaxis owns: we use commercial facilities, and the operator's own attestations are what you should read before committing hardware.

  • Carrier-neutral commercial facilities with redundant utility feeds and generator-backed power
  • Redundant cooling with continuous environmental monitoring
  • Controlled physical access with logged, attributable entry
  • Redundant upstream network with physically diverse paths
  • Fire detection and suppression appropriate to a live equipment hall
  • Facility certifications and audit reports provided to you for review before you commit hardware

Connectivity and edge

Network design is where latency, cost and blast radius are all decided at once, usually before anyone is paying attention. We segment aggressively, route deliberately, and put nothing on a public interface that does not have to be reachable from one.

  • Segmented private networks, with public exposure limited to endpoints that must be public
  • Redundant upstream connectivity and diverse routing at the facility level
  • Private links between colocated hardware and cloud environments, avoiding the open internet where it can be avoided
  • Load balancing, TLS termination and automated certificate renewal
  • DNS management with health-checked failover, and CDN in front of public endpoints
  • DDoS mitigation and edge filtering through managed edge providers, so absorbing an attack is not your origin's job

Default deny

Every environment we build starts closed. It is opened one justified rule at a time, and each rule has a reason attached to it. Access is granted by role, reviewed on a schedule, and logged. Secrets live in a secret store, not in a repository, not in a configuration file, and not in a chat thread.

  • Default-deny network policy; every ingress rule justified and attributable
  • Role-based access with least privilege, and mandatory multi-factor authentication for anything administrative
  • Secrets held in a managed secret store with rotation. No credentials in code, images or configuration
  • Encryption in transit and at rest as the standard build, not as a paid option
  • Immutable, centralised audit logging with a defined retention period
  • An agreed patch cadence, plus an emergency path for critical vulnerabilities

On certification: we are not a certification body and we do not sell you a certificate. What we provide is the control implementation, the operational discipline behind it, and the evidence trail your auditor asks for.

What we commit to,
in writing

We do not publish a headline uptime figure, because a percentage with no contract behind it is decoration. Availability targets, severity definitions, response times and maintenance windows are agreed per engagement and written into the service agreement before anything goes live.

  • An availability target defined per service tier and stated explicitly in the agreement
  • Severity levels, each with a committed first-response target
  • A named escalation path: you know who gets called, and at what point
  • Scheduled maintenance windows notified in advance; emergency changes documented immediately afterwards
  • Backups with a stated recovery point and recovery time objective
  • Post-incident reviews shared with you, including the specific change made so it does not recur

How an engagement runs

You keep ownership throughout. The cloud accounts, the repositories, the infrastructure code and the data are yours from day one. If you decide to leave, you leave with a working system and the documentation needed to run it. We would rather be kept than be difficult to remove.

  1. Assess. We review what you run today: architecture, dependencies, cost, risk, and the parts nobody wants to touch. You receive a written summary of what we found.
  2. Design. Target architecture, migration sequence, rollback plan and cost model, agreed with you before a single change is made to anything live.
  3. Build. Environments provisioned from code, pipelines wired, monitoring and alerting in place before the first production workload lands on them.
  4. Operate. Monitoring, patching, backup verification, capacity review, and a scheduled report you can actually finish reading.

Client engagements

Two engagements published here, each with the client's agreement and limited to what they publish themselves: Claimstant, a claim-linked funding platform for commercial-vehicle insurance built around a seven-state controlled transaction, and ThrowdownLive, a livestreaming platform for Throwdown Media, now in early access. Other engagement details are not published without agreement. Scale, architecture and outcomes are shared directly during technical evaluation.

Send us your architecture.
We'll tell you what we'd change.

Contact Us

No forms. Email or call us directly, tell us what you are running, and you will get a technical answer rather than a sales sequence.

Landline

044 22350611

WhatsApp

+91 88386 43673

Fastest route for a first conversation.

Response

Enquiries are answered within one business day. Clients already under a support contract should use the escalation path in their service agreement rather than this page: it is monitored differently.

Hours

Monday to Friday, Indian Standard Time (UTC+5:30).

Registration
Gravaxis Infrastructure LLP
LLPIN: ACY-2772
GST: 33ABEFG6678F1Z9
Chennai, Tamil Nadu, India
What to tell us

A useful first message answers four questions. If you can cover these, we can usually give you a real opinion in the first reply.

  • What you run today: public cloud, on-premise hardware, or a mix of both
  • Roughly how big it is: number of services, environments, users, data volume
  • What is actually hurting: cost, downtime, an audit deadline, a migration, a person who left
  • Whether you want us to build it, run it, or both
What happens next
  1. Reply within one business day, with whatever we still need to know.
  2. A technical call, thirty to forty-five minutes, no slides.
  3. A written summary of what we would do, roughly what it would cost, and anything we would advise you not to do.

There is no obligation at any stage, and we will say so directly if we are not the right fit for the problem.

Partnerships

Data centre operators, hardware vendors, and consultancies looking to place infrastructure workloads: the same channels reach us.

Prefer to just talk?