Choosing packages

gisila or gisila_doc?

Both are the same MVC framework. gisila_doc adds OpenAPI 3.1 generation on top: controllers carry tags, summaries and response types, and the generator writes the spec and the route registration together.

• Choose gisila for internal services, small APIs, or when you don’t need a published contract.
• Choose gisila_doc when other teams or clients consume your API, or when you want Swagger UI, ReDoc or generated client SDKs.

Switching later is cheap, because the controller style is the same. See Migrating from gisila.

Do I need gisila_orm?

• Yes if you use PostgreSQL and want typed models, migrations and safe query building.
• No if you use another database, or only a few hand-written queries. The framework’s database integration is pluggable, so you can use package:postgres directly. See Framework → database.

Do I need gisila_queue?

Use a queue when a request would otherwise wait on slow or unreliable work: sending email, calling third-party APIs, generating files, or anything that needs retries. If the work is quick and must finish before you respond, do it in the request.

Broker	Pick it when
In-memory	Tests and single-process apps
Redis	You already run Redis and want the simplest distributed setup
RabbitMQ	You need AMQP routing or already operate RabbitMQ

Do I need gisila_studio?

Add it when operators or support staff need to look up and fix records. It is generated from your ORM tables, so it costs only a few lines. Always put it behind authentication (see Studio security).

Do I need gisila-panel?

The panel is optional. Gisila apps compile to a normal executable and run anywhere. Use the panel if you want git-push-style deploys, managed Postgres and Redis, domains with TLS, cron jobs and logs on a server you control. See When to use the panel.

Typical setups

Project	Packages
Small internal API	gisila
Public REST API with docs	gisila_doc + gisila_orm
SaaS backend	gisila_doc + gisila_orm + gisila_queue + gisila_studio, deployed on gisila-panel