Compliant on the day you install it.
Setu is a Government-of-India-compliant CMS framework for departments and urban local bodies. It ships 100% compliant out of the box: every rule a framework can satisfy is already satisfied, and the rules that depend on how a portal is run are automated and enforced by AI so they stay satisfied.
// the_overview
Most government portals are built compliant once, then drift. A page is published without its official-language version, an image goes up without alt text, an approval is skipped on a busy day — and by the time an STQC auditor arrives the site no longer matches the certificate. Setu is designed so that drift cannot happen quietly.
Everything a framework can guarantee is guaranteed by the framework: GIGW 3.0 checkpoints, WCAG 2.2 AA gating, a hash-chained audit trail, DPDP consent artefacts with SLA clocks, RTI §4(1)(b) structure, Unicode only across every Indian script, versioned OpenAPI, ODF and PDF/A handling, and C2PA provenance on anything AI touched. setu init produces a site that is already compliant. You do not configure it to comply — you configure it to deviate, and every deviation is recorded.
Everything that depends on how the portal is used — is the content genuinely in the deployment's own official language or English typed into a translated field, is the alt text meaningful, did a human actually check the accessibility of this page, is this notice written plainly enough for a citizen — is where AI takes over. It writes, translates, checks and blocks, so the second half of compliance is enforced continuously rather than audited annually.
It is a framework, not a platform. A developer extends it in TypeScript through one module interface, rebuilds, and ships an image — which is why it stretches from a district notice board to a full application portal or a citizen mobile app without a plugin sandbox, a registry, or a permanent security surface to defend.
// the_problem
Language is not a preference in Indian government. The Official Languages Act of 1963 binds the Union to Hindi and English, and every state has its own official language act binding its departments, semi-government bodies and local bodies — notices, orders, correspondence and websites alike. Most portals treat the language as a translation job at the end of the build. The evaluation committee treats it as the first thing it checks.
The rest arrives as a stack of separate instruments. GIGW 3.0 scores a site against 88 mandatory checkpoints. CERT-In gives six hours from noticing an incident to reporting it, and requires 180 days of logs held inside India. DPDP wants consent artefacts and a 72-hour breach report. RTI §4(1)(b) wants seventeen disclosure categories. A general-purpose CMS answers none of them.
And then there is the half no schema can hold. Whether the text on the page is really in the language its field claims. Whether the alt text describes the photograph or repeats its filename. Whether two officers signed a maker–checker approval or one signed twice. A portal can carry every correct field and still hand an auditor an empty record.
88
mandatory GIGW 3.0 checkpoints a government website is scored against
6 h
from noticing an incident to reporting it to CERT-In
180 days
of system logs, retained on infrastructure inside India
// how_it_works
Setu is a CMS framework built for Tier A — government departments and urban local bodies. Four decisions define it: how it is extended, what a fresh install already enforces, what AI checks where a schema cannot reach, and how far a single instance stretches.
Setu is extended at build time, through one SetuModule interface: an npm install, a config line, a rebuild. That deletes the plugin sandbox, the capability manifests, the artifact signing, the registry and the plugin-by-kernel matrix a runtime CMS defends forever.
A fresh site already has the GIGW mandatory pages, official-language-first locales, the accessibility gate armed, maker–checker on, the audit chain running and DPDP consent in place. Which official language comes first is the deployment's own declaration — any of the 22 scheduled languages, English second. You do not configure Setu to comply. You configure it to deviate — and every deviation is recorded.
Some obligations depend on how a portal is used, not on how it is built. Setu puts those under AI review at every publish: the language, the alt text, the readability of a notice, the reality of an approval, the labelling of generated output.
Runtime is one Node process and PostgreSQL; storage, cache, virus scanning and search are modules with local or no-op defaults. The same interface that adds a district notice board adds a grievance portal, a scheme-application system, a full application portal, or a mobile backend.
// what_it_ships
Each of these is its own package, versioned in lockstep with the kernel and published to a private registry. A deployment lists the ones it wants in its own setu.config.ts and rebuilds.
Content types & revisions
Every document type gets revisions, locales, workflow and the publish gate for free.
Workflow FSM
Draft to published, per locale, with maker–checker separation of duties enforced.
The field contract
One validator and one renderer, shared by the admin, blocks and in-place editing.
The accessibility gate
Thirteen rules over parsed HTML, field by field. Eleven of them stop a publish.
Media pipeline
Sniffing, allowlist, quarantine, virus scan, derivatives, and a per-locale alt-text gate.
i18n & the official-language glossary
An ICU catalogue for any of the 22 scheduled languages, XLIFF and CSV exchange, and a linter that fails on hardcoded text.
Identity
TOTP, WebAuthn passkeys, CASL capabilities, lockout, and eight system roles from install.
The setu CLI
One binary: init, migrate, doctor, audit verify, update, backup and restore.
// the_two_layers
The compliance claim has two halves and they only mean anything together. The left column is what a framework can settle at install, and therefore does. The right column is what depends on how the portal is used — put under AI review before anything goes live.
Armed at install, on every instance. Not a switch an operator can forget.
The half a schema cannot hold. Checked against the draft, before it goes live.
What this does not claim. VAPT by a CERT-In empanelled auditor, STQC certification, MeitY-empanelled hosting inside India, and the manual NVDA and JAWS pass on Indian-language content are procedural and per-deployment — no software produces them. Every checkpoint reports pass, fail, or manual-audit-required, and manual is never counted as a pass.
// setu_in_numbers
13
accessibility rules over every field before publish — eleven of them block
33
compliance checkpoints: 19 automated, 14 permanently manual-audit-required
1 Node
process plus PostgreSQL. Storage, scan and search are optional modules
22
scheduled Indian languages plus English. The default is the deployment's own
// the_highlights
setu init produces a site with GIGW page furniture, official-language-first locales — each deployment declares its own default from the 22 scheduled Indian languages plus English — the accessibility gate armed, maker–checker on, the audit chain running and retention configured. Nothing has to be switched on.
The checks a framework cannot make — is this really in the declared language, is this alt text meaningful, is this notice readable — are made by AI on every publish, and a failure blocks the publish rather than filing a warning.
Thirteen WCAG 2.2 AA and GIGW rules run over the parsed HTML of every page. Eleven of them stop the publish outright. An inaccessible page never reaches a citizen in the first place.
Every action is a hash-chained, append-only record. setu audit verify proves the chain is intact, and a one-click evidence pack assembles what an STQC submission asks for.
One module interface adds content types, fields, blocks, admin screens, routes, jobs, providers and migrations — so the same framework serves a notice board, a grievance portal, a scheme-application system or a mobile app backend.
A district instance runs on a single Node process and PostgreSQL. Object storage, virus scanning, cache and search are modules with local defaults you adopt only when you outgrow the disk.
// stack
// faq
// next_step
Tell us what you're trying to run. We'll show you the product working, scope the deployment, and give you a straight answer on timeline.
