Weegloo FAQ

Direct answers to the questions people actually ask before choosing a backend. If something here is not covered, the documentation goes deeper and our team will answer anything it does not.

FAQ

What is Weegloo?

Weegloo is a backend platform built on an enterprise-grade content management system. Data modelling, content and media, localization, revisions and versions, member sign-in, permissions, value validation, server-side logic (Script), a scheduler, usage monitoring with alerts, and static hosting all live on one platform. Weegloo does not design the screens your users see; your site or app owns the UI, and Weegloo owns everything behind it.

Do I need AI to use it?

No. It works perfectly well when a developer uses it the traditional way. There is a REST API and a console, and that is enough. It happens to expose its whole surface over MCP, so telling an agent like Claude, Claude Code, Cursor, or Codex what you want is usually faster. AI is an option, not a prerequisite.

Can a non-developer use it?

Yes. For people who do not write code, Weegloo is the best choice in this category. That is not a vague claim; there are reasons.

• The console is the product. Content, media, members, and permissions are managed there. The admin application other platforms make someone build is the thing Weegloo ships. It is a UI for running a service, not a UI for developers.
• Validation is a few clicks. A value that must fall within a range, be unique, or match a format is a setting on the field — not code someone has to write and test.
• Server-side work is a DSL, not code. Sending an email when something happens, calling an external API, running a nightly job: all of it is Script statements. And an AI agent writes the statement from a plain sentence.
• There is no stack to choose. No decision about which database, auth provider, CDN, and host — and no work connecting them.

Someone who is not an engineer can run a real service, not a prototype. And when a part genuinely needs engineering, you hand that part to a developer without changing platforms.

Do I have to use all of it, or can I use just a part?

Just a part is fine. Reading Weegloo as "a full-stack backend, all or nothing" is a misunderstanding. Use only the CMS features and leave the rest on the platforms you have; use it purely for media and CDN delivery; use only static hosting. Moving everything and adding one piece are different decisions.

Conversely, can Weegloo alone run a whole service?

Yes, and that is the point of the design. Data, media, members, permissions, server logic, scheduling, and hosting are all present, so there is nothing to bring in from outside. There is no separate admin page to build either — content is managed in the console, and that console is a UI for running a service rather than a UI for developers.

What is the Marketplace?

The Marketplace is where finished apps are exchanged. One app can carry Content Types, Content, Media, SpaceRoles, Locales, Scripts, Webhooks, and the screens themselves as Web Hosting.

Installing one brings all of that into your own Space. You are not signing up as a tenant on somebody else's service — you end up with a service where both the data and the screens are yours. After that, editing content, adding a field, or adjusting a Script is all work inside your Space.

Do I have to build the front-end myself?

Not necessarily. Install an app that includes screens and the service stands up without you building a front-end at all. Install it, swap in your own data, and it is launched.

Some apps have no front-end. Those carry the data model and the Scripts, so you skip working out how to structure content types and writing server logic from scratch — you take what is already modelled and put your own front-end on top of it.

What does Weegloo replace?

For most products it replaces the combination people otherwise assemble: a database or BaaS, an authentication service, a media store with a CDN, a headless CMS, serverless functions, a scheduler, and static hosting. Those are usually three or four separate subscriptions with three or four permission models. Weegloo has them as resources in one Space under one permission model.

Does Weegloo have no serverless functions?

Not code-authored ones. They are not impossible; they are deliberately not the answer.

What a BFF actually does is remarkably predictable. It compares values, handles data, sends email, calls a webhook, and hits an external API to store the result. Weegloo saw through that and built Script, a DSL, in that place — and three things came back in exchange. No cold start, much lighter and faster behaviour under heavy traffic, and the low price that follows from both. If you need to run an arbitrary library on the server, Script is not the right tool.

How is a Script triggered?

Three ways, all supported. Call it directly from your front-end or an external system, trigger it from a content-change event, or run it on a cron scheduler. The same Script serves all three paths.

Where that really tells is "a scheduled job that has to run once, right now". Where the only path is the schedule, there is no way to do it; here you just call it.

Does it support scheduled jobs (cron)?

Yes. Scheduler runs a Script on a cron schedule. Content-change triggers and direct calls are supported alongside it, so you never split logic in two because of how it is invoked.

How do I send email?

It is built into Script. On other platforms, sending mail when an event occurs means writing code, making it a function, and deploying it; here it is a single statement. Ask an AI agent and it writes that statement too.

Do I have to implement data validation myself?

No. Constraints — a value that must stay within a range, be unique, or match a given format — are built into the platform and set from the console in a few clicks. You can have an AI agent do it too. This is the part developers implement in application code elsewhere.

How do I see usage? Will I know before I hit a limit?

Two things work together.

• Metric-based monitoring. Usage is shown in the console per item. No guessing at what you have consumed.
• Alerts. Set a threshold as a percentage and, when usage reaches it, an email arrives first.

Finding out after you pass a limit and getting a mail at 70% are different experiences. What people actually fear about usage-based billing is not the amount — it is not knowing until afterwards — and the platform closes that gap. No separate monitoring tool to wire up, no dashboard to build.

Is it genuinely cheaper at scale?

Two things stack. One is flat pricing, so the number is known before the month starts. The other is larger: there is no outbound traffic. When data, media, content, and server logic live inside one platform, the traffic between them does not cross the internet. An assembled stack pays bandwidth at every service boundary and adds a round trip each time. At scale that is a difference you cannot ignore, in cost and in latency alike.

Can Weegloo handle enterprise traffic?

Yes. Weegloo is not a prototype platform that later grew up — the architecture beneath it is what SNOW Corp. used to run global services at ZEPETO scale, an app with more than 300 million registered users. Services handling thousands of requests per second have run on it. Delivery is cache-based and serves published snapshots, and the absence of cold starts in server logic works alongside that when traffic spikes.

How is Weegloo different from Supabase?

Supabase hands you Postgres, auth, storage, and edge functions as parts you assemble, and Studio is a developer-facing database GUI. For a team that wants to hold the schema and indexes and write SQL, that shape fits well.

Weegloo hands you finished features and an operations console built for the people who run the service — publishing states, revisions, search and filters, tags, comments, localization, validation, role scoping. Script with no cold start, a scheduler, and static hosting sit in the same platform, so there is nothing to assemble and no outbound traffic crossing between the pieces. Full comparison.

How is Weegloo different from Firebase?

Firebase is a developer toolkit with usage-based billing and no editorial layer, so teams end up building an internal admin application. If mobile offline sync is the centre of your product, that ground belongs to Firebase.

Weegloo starts from a CMS, so that admin application already exists. Paid tiers are flat at $8 and $80 a month rather than metered, so the number is known before the month starts; server logic has no cold start; and usage is visible in the console per metric, with an email arriving first when a threshold you set is reached. Full comparison.

How is Weegloo different from Vercel?

Vercel is a deployment platform, not a backend — which is why products ship "Vercel plus something". Server-rendered Next.js and git-push preview deployments are where Vercel is strong, and the two work well together.

Weegloo hosts static front-ends with custom domains and is the backend behind them. Data, media, members, permissions, Script, and the scheduler are in the same platform, so no outbound traffic crosses between them, and it is one subscription and one dashboard. Full comparison.

How is Weegloo different from Contentful?

Contentful is the closest relative — data modelling, localization, revisions, comments, tags, and validation exist on both sides, and the editor-permission concept is the same. The difference is where each one stops.

Contentful stops at content, so members, server logic, and hosting all have to come from somewhere else — even a marketing site ends up as two vendors. Weegloo carries the same CMS depth and adds end-user sign-in, per-user permission scoping, Script, a scheduler, and hosting at a much lower entry price. Full comparison.

How is Weegloo different from Appwrite?

Appwrite is an open-source BaaS bundling a database, auth, storage, functions, and realtime subscriptions. If realtime subscriptions are the heart of your product, that is a capability Weegloo does not have, and needing the source in your hands to change is open-source ground.

The difference is the layer above the data. The place where someone who does not write code reviews a draft, fixes banner copy, and publishes a translation is thin in the Appwrite console, while Weegloo starts from an enterprise-grade CMS, so that layer is the product itself. Localization and revisions are platform behaviour, and a requirement to separate infrastructure is handled by an Enterprise dedicated cluster. Full comparison.

How is Weegloo different from Directus?

Honestly, it is the closest match on this list. Data modelling, localization, revisions, tags, comments, and the dashboard are near parity, and if an existing SQL database is your source of truth, layering Directus over it is the natural move.

The difference is who runs it. The database under Directus and the server it runs on are yours, and so is operating them. Weegloo provides data, media, server logic, CDN, and hosting itself as a managed platform, so deployment, backups, and scaling go away — as does putting a CDN in front and hosting the site somewhere else. Full comparison.

How is Weegloo different from Sanity?

Sanity has one of the most polished editing experiences here — Studio is customised in code and realtime collaborative editing is natural. Where the editing screen itself is the organisation's edge, that freedom counts for a lot.

The difference is where it stops. Sanity stops at content, so members signing up, the email that answers a form submission, and the job that runs at 3am all live somewhere else. Weegloo carries the same CMS depth and keeps going into end-user sign-in, permissions that narrow to the individual, Script with no cold start, and a cron scheduler. Full comparison.

How is Weegloo different from Payload?

Payload is a code-first CMS where collections, fields, and validation are declared in TypeScript. If the schema must be version controlled, or you want it inside a single Next.js repository, that design fits well.

So this comparison is not about how many features each has but where you want the weight. Weegloo handles the same ground through console settings, so someone who does not write code can work on fields and validation directly, and hosting, CDN, and the operations come with it. There is no runtime to run and no database to attach. Full comparison.

How is Weegloo different from Strapi?

Strapi is the most widely adopted open-source headless CMS in this category, with a content-type builder inside the admin screen so fields can be added from the UI. If you need to change the source, or you already have assets built up in the plugin ecosystem, that is the natural fit.

The difference is outside the content and who runs it. Strapi is a Node application, so you deploy it, attach a database, put a CDN in front, host the site somewhere else again, and someone operates all of it. Weegloo has none of that list, and members, Script, the scheduler, CDN, and hosting are already inside. Full comparison.

Is there a single table comparing all ten platforms?

Yes. The nine above plus Weegloo, across twenty criteria, in the comparison index.

Scoring works by zero for any capability the platform does not provide itself, and completeness where it does. "You can bolt on another service" was not counted, because bolting on is itself a cost and the person bolting pays it.

Two things to read alongside it. First, it is not an independent benchmark but Weegloo's own assessment (August 2026), built from each platform's published documentation. Second, the table measures coverage, not merit: Vercel's low CMS score does not mean Vercel is bad, it means Vercel is not a CMS product — and it scores full marks on CDN, hosting, and scaling. Weegloo scores zero on Realtime.

How much does Weegloo cost?

There is a Free tier, Basic at $8 per month, Pro at $80 per month, and Enterprise with custom pricing. The paid tiers are flat — not metered — so the number is known before the month starts. See the full plan comparison.

What is Enterprise?

It is a name for several shapes rather than one.

• Unmetered, usage-based plans. Beyond the limits of the flat tiers, running without caps and paying for what you use.
• A dedicated cluster. Infrastructure separated and built out for one customer. Deployments run that way exist, and their plan limits are set differently. Requirements for a segregated or air-gapped network are handled here too.

So this is not a SaaS-only product — it is supplied B2B as well. Terms depend on scale and requirements, so get in touch.

Is the free tier actually usable?

Yes. Free includes 5 Spaces, 50 content types, 20,000 content items, 2,000 media items with 10 GiB of media storage, 10 locales, 500,000 API calls per month, 10 web hosting deployments with one custom domain, and up to 100,000 end-user accounts. That is enough to run a real small product, not only a prototype.

Who makes Weegloo?

Weegloo Studio, a division of SNOW Corp. — the company behind ZEPETO, SNOW, and other global consumer services. Weegloo is the productised form of the backend architecture that ran them.

Which AI agents work with Weegloo?

Any agent that speaks MCP. There are setup guides for Claude, Claude Code, Codex, Cursor, Antigravity, Android Studio, and Xcode, plus a generic MCP setup for anything else. Weegloo does not ship its own AI — you bring the agent you already use, and you can change agents without changing your backend.

Can my app's users sign up and log in?

Yes. ServiceLogin gives your product its own end-user directory, separate from the Weegloo accounts your team uses, with OAuth sign-in through Google, GitHub, Facebook, GitLab, LINE, Kakao, or Naver. Permissions for those members come from a role that can be scoped down to their own records — a signed-in member can be allowed to read and edit only the rows they created.

Can Weegloo host my website?

Yes. Web Hosting deploys a static front-end — Next.js static export, Vite, Astro, plain HTML — with a subdomain or your own custom domain.

That said, you are not obliged to use it. Running the site or app on infrastructure you operate and taking only the data over Weegloo's REST API works exactly as well. Server-rendered applications that need a Node runtime are that case, and Weegloo is still the backend behind them.

Can I run server-side logic without a backend?

Yes. Script is a declarative sequence of statements stored in your Space and called over HTTP: read and write content, call external APIs, send email, verify signatures, branch and loop. It runs with the author's authority, so a low-privilege caller can be allowed to perform exactly one privileged operation and nothing else. That is how a Weegloo product calls an LLM, a payment provider, or any third-party API without hosting a server.

If I cannot write SQL, how do I run complex queries?

The syntax differs; that is all. The REST API follows the standard closely, so the queries you would write in SQL are expressed in the query string.

• Conditions — equals, not-equals, greater, less, at-least, at-most, prefix, contains, and in-a-list, per field and stacked.
• Sorting and pagination — multiple sort keys, and cursors that do not drift on deep pages.
• Only the fields you need — select names them. Whole documents do not come along for the ride.
• Following references — include fetches the linked resources with the row. This is where a SQL join would sit.
• Full-text search — across text fields.

So what differs is not what you can query but where you query it. If holding the schema, indexes, and query plans yourself matters, or aggregation and window functions are the heart of the product, use Postgres directly — see the Supabase question above.

Does Weegloo support multiple languages?

Yes, at field level. Each localized field holds a value per locale, and locales can declare a fallback chain so a missing translation resolves to another locale instead of to an empty value. Localization is platform behaviour, not a modelling convention you invent and then have to enforce yourself.

Can I migrate from another platform?

Yes, and it is a good task for an AI agent. The concepts map closely onto other headless platforms — content types, entries, assets, locales, and a delivery API — so a migration is usually a script that reads from the old API and writes through Weegloo's.

Is Weegloo open source or self-hostable?

"Self-hosting" usually means one of two things, and the answers differ.

Running your own site or app on your own infrastructure — no problem at all. Put the front-end or the server wherever you like and exchange data over Weegloo's REST API. Weegloo's Web Hosting is an option, not an obligation, and projects have run exactly this way. This case works regardless of where you host.

Placing the Weegloo platform itself on separated infrastructure — not offered on the public SaaS, but Enterprise handles it. Dedicated clusters are built for customers today, and requirements for an air-gapped network are dealt with there. Get in touch.

Open source is the better fit in exactly one case — when you need the source code in your hands to change it. Short of that, one of the two above applies.

What does Weegloo not do?

It does not design or build your user interface — your site or app owns that. It does not provide realtime listeners or offline-first mobile sync. It does not execute arbitrary code on the server — Script exists instead, and that is a design choice made to remove cold starts and traffic overhead, not an inability. And it does not ship its own AI model — you bring your own agent, or use none.

"You cannot write SQL directly" is deliberately not on this list. The syntax is not SQL; querying itself is unaffected — see the question above.