CMS headless multi-tenant e API-first. Il percorso di lettura non arriva mai all'API — quando crescono i visitatori, a salire è il tasso di cache, non la fattura.
I suoi dati risiedono su server gestiti da noiNessun servizio esterno a consumoInstallazione sui suoi server con il piano Enterprise
Ogni componente sulla nostra infrastruttura
Funzionalità
Tutto sta dietro l'API; nessuna funzionalità è chiusa nel pannello.
Ogni progetto è uno spazio a sé. L'isolamento vive nel database, non nell'applicazione: la sicurezza a livello di riga di PostgreSQL impedisce che i dati di un tenant finiscano in un altro, anche quando il livello applicativo sbaglia.
I tipi di contenuto non sono scolpiti nel codice; li definisce dal pannello o tramite API. I campi portano ruoli come title, slug e body — la pipeline di build e la generazione SEO guardano il ruolo, non il nome del campo.
Media, ricerca, webhook, SEO, GraphQL, importazione, analytics — ciascuno separato e disattivabile. Disattivare non cancella dati; riattivi il modulo e riprende da dove si era fermato.
I contenuti pubblicati vengono scritti a un indirizzo immutabile in fase di build e serviti dalla cache edge di nginx. Né il numero di voci né quello dei visitatori alza il costo di una lettura.
Archiviazione oggetti compatibile S3 (Garage), immagini replicate su tre zone e derivati automatici. I file che carica restano sulla nostra infrastruttura e non finiscono mai su una CDN a consumo.
Ricerca full-text multilingue basata su Typesense. Anche chi digita «Istanul» trova il contenuto giusto, e la risposta torna in meno di 50 millisecondi.
Pubblicazione, aggiornamento, eliminazione — a ogni evento i suoi sistemi vengono avvisati. La consegna resta in una coda durevole e viene ritentata con backoff esponenziale; anche se il processo muore, l'evento sopravvive.
Lo schema non si scrive a mano: viene derivato dai tipi di contenuto dello spazio. Aggiunge un tipo e diventa interrogabile. I limiti di profondità e lunghezza sono obbligatori, come difesa dalle query bomba.
@corpusctl/client con adattatori per React, Vue e Next.js. I renderer dei blocchi arrivano con zero stile predefinito — non imponiamo una riga di CSS, il design è interamente suo.
Esempi di codice
Tutto ciò che può fare nel pannello ha un equivalente API; nessuna funzionalità è chiusa nell'interfaccia.
# 1) Definire il tipo di contenuto — lo schema non è scolpito nel codice
curl -X PUT "$API/v1/content-types/post" \
-H "authorization: Bearer $TOKEN" \
-H "x-corpusctl-tenant: $TENANT" \
-H "content-type: application/json" \
-d '{
"name": "post",
"title": "Post",
"fields": [
{ "name": "title", "type": "text", "role": "title", "required": true },
{ "name": "slug", "type": "slug", "role": "slug", "required": true },
{ "name": "body", "type": "blocks", "role": "body" }
]
}'
# 2) Creare una bozza
curl -X POST "$API/v1/documents" \
-H "authorization: Bearer $TOKEN" \
-H "x-corpusctl-tenant: $TENANT" \
-d '{ "type": "post", "data": { "title": "Hello", "slug": "hello" } }'
# 3) Pubblicare — validazione, build e distribuzione all'edge in una sola chiamata
curl -X POST "$API/v1/documents/$ID/publish" \
-H "authorization: Bearer $TOKEN" \
-H "x-corpusctl-tenant: $TENANT"
# → { "data": { "version": 3, "contentHash": "…", "durationMs": 42 } }import { ReadClient } from '@corpusctl/client'
import { Content } from '@corpusctl/react'
// ReadClient NON porta alcun token e non chiama mai l'API — legge direttamente dall'edge.
const client = new ReadClient({
tenantId: '3f2b…',
edgeUrl: 'https://cdn.example.com',
manifestTtlMs: 60_000,
})
export default async function Page({ params }) {
// slug → calcolo dello shard (locale) → manifest → indirizzo immutabile.
// Due richieste HTTP, entrambe dalla cache. Se non trova nulla restituisce undefined,
// non solleva errori — la decisione sul 404 spetta alla sua pagina.
const post = await client.getBySlug(params.slug)
if (!post) notFound()
return (
<article>
<h1>{post.data.title}</h1>
{/* Zero stile predefinito: ogni tipo di blocco può essere sovrascritto */}
<Content value={post.data.body} components={{ ... }} />
</article>
)
}# Lo schema non si scrive a mano: viene derivato dai tipi di contenuto dello spazio.
# Nel momento in cui definisce il tipo «post», diventa interrogabile.
query GetPost($slug: String!) {
post(slug: $slug) {
title
slug
body
# Anche i campi calcolati sono nello schema: tempo di lettura, numero di parole…
readingTime
}
}
# Query di lista — paginazione a cursore, senza offset
query LatestPosts {
postList(limit: 10) {
data { title slug }
cursor
}
}ReadClient non porta token segreti e può girare nel browser; ManagementClient resta lato server. Se fosse un'unica classe, far trapelare un token sarebbe un errore da una riga.Architettura
Il pulsante Pubblica avvia una build; il visitatore legge il risultato di quella build, non il sistema.
Il contenuto è indirizzato tramite il suo hash. Lo stesso indirizzo non restituisce mai un contenuto diverso, quindi può restare in cache 30 giorni; al momento della pubblicazione il manifest viene aggiornato.
Quale shard del manifest leggere viene calcolato dallo slug sul client. Anche in uno spazio con diecimila voci si scarica un solo file di piccole dimensioni.
Ogni record è versionato e una versione precedente può essere ripristinata nella bozza. La pubblicazione può essere pianificata a una data futura; è lo scheduler stesso ad avviare la build.
Confronto
Non vinciamo ogni riga. Questa tabella esiste perché veda con chiarezza che cosa sta scegliendo.
| Criterio | corpusctl | Contentful | DatoCMS |
|---|---|---|---|
| Modello di prezzo | Piano fisso. Poiché le richieste di lettura non arrivano all'API, non c'è alcuna chiamata da misurare. | A consumo per chiamata API, record e utente; extra in caso di superamento. | A consumo per chiamata API e per banda. |
| Gestione multi-progetto | Nel nucleo del prodotto. Un pannello, spazi illimitati; l'utente ha un ruolo distinto in ciascuno. | Ogni progetto è uno «space»; nella maggior parte dei piani si paga per space. | Ogni progetto è un ambiente a sé; un piano per progetto. |
| Isolamento dei tenant | A livello di database — sicurezza a livello di riga di PostgreSQL (RLS). | A livello applicativo; dettagli non divulgati. | A livello applicativo; dettagli non divulgati. |
| Ubicazione dei dati | Server gestiti da noi; con il piano Enterprise interamente sui suoi server. | Il cloud del fornitore; scelta della regione nei piani superiori. | Il cloud del fornitore; scelta della regione nei piani superiori. |
| Servizi esterni a consumo | Nessuno. PostgreSQL, Valkey, Typesense, Garage, nginx — tutto sulla nostra infrastruttura. | Sì; i livelli di ricerca, immagini e CDN sono a consumo. | Sì; CDN immagini e trasformazioni sono a consumo. |
| Rendering imposto | Nessuno. I renderer dei blocchi arrivano con zero stile predefinito; un blocco sconosciuto viene saltato, mai fatale. | È fornito un renderer rich text; le scelte di stile restano sue. | È fornito un renderer di testo strutturato; le scelte di stile restano sue. |
| Disattivare funzionalità | Ogni funzionalità è un modulo disattivabile; disattivare non cancella dati, e nemmeno il passaggio a un piano inferiore. | I limiti di piano rendono la funzionalità inaccessibile. | I limiti di piano rendono la funzionalità inaccessibile. |
| Rete edge globale | Cache edge su una sola regione. Non abbiamo una rete di PoP globale. | CDN globale su più regioni. | CDN globale su più regioni. |
| Marketplace di app | Nessuno. Le integrazioni si scrivono con webhook e API. | Un ecosistema di app ampio e maturo. | È disponibile un ecosistema di plugin. |
| Maturità enterprise | Prodotto giovane; SSO e uno SLA formale sono nella roadmap. | SOC 2, SSO, SLA — maturo. | SSO e SLA nei piani superiori. |
Creare un account richiede pochi minuti: bastano un indirizzo e-mail, una password e un nome per il suo spazio. Non chiediamo la carta. Se le serve aiuto per migrare, ci scriva.