Frequently Asked Questions
Learn how Lino accelerates .NET projects with Clean Architecture, DDD, CQRS, JWT, multi-tenancy, shadow entities, RabbitMQ, Hangfire, Blazor, caching, observability and deployment.
Lino is a CLI for generating modern applications in .NET.
It automates architecture, modules, APIs, authentication, frontend and infrastructure with a focus on Clean Architecture, DDD and CQRS.
Lino helps reduce the repetitive work involved in starting and evolving .NET applications.
Instead of manually assembling the solution, layers, endpoints, authentication and initial deployment, the team starts from a ready-made base and focuses on business rules.
Lino is a code generator for .NET, not a closed framework.
After generation, the project belongs to the team and can be modified without mandatory dependence on the tool.
The main focus of Lino is deterministic generation based on templates and rules.
This helps maintain predictability, architectural consistency, and less noise than AI-dependent flows.
Lino was created by Eduardo Tolino to increase productivity and standardize the architecture of modern applications in .NET.
Yes.
The generated projects use common enterprise software patterns, such as Clean Architecture, CQRS, DDD, JWT, Docker, observability and pipeline integration. The generated base should still be reviewed, tested and configured for each production environment.
The main difference of Lino is to accelerate the creation of .NET applications with a consistent architectural base from the first command.
It combines code generation, modular organization, APIs, frontend, authentication, events, and infrastructure into a single flow.
To use Lino you need to have installed .NET SDK, Git, Entity Framework CLI and Docker.
dotnet tool install --global Tolitech.Lino
After installation you can check the version with lino --version.
lino project new --name MyProject
This command creates the initial project structure with layers, modules, and base configurations.
Lino can generate project structure, services, modules, entities, value objects, enumerations, commands, queries, APIs, pages, events, event handlers, migrations, background jobs, secrets configuration and Docker images, depending on the selected features.
Yes. The generated code is completely yours and does not depend on the tool to continue working.
Yes. Lino is a good option for MVP when you want speed without giving up a clean base to evolve later.
Yes. Lino helps SaaS projects that need an organized backend, authentication, APIs, web frontend, standardized infrastructure, tenant isolation, permissions by context, secrets management and rate limiting.
Yes. Lino was designed for business applications in .NET that require separation of layers, well-defined modules, APIs, events and integration with real infrastructure.
Both scenarios are valid. For most products, starting with a modular monolith is often simpler and more cost-effective.
Lino makes sense when you need to deliver a .NET project with a consistent architecture, quick setup and room to grow without rewriting the base.
If the project is extremely small, disposable or does not require a modular architecture, the gain of Lino may be lower.
Yes. The gain is in eliminating hours or days of repetitive setup for backend, frontend, authentication, endpoints, events, persistence and initial infrastructure.
.NET teams that build web products, SaaS, internal systems, B2B platforms and enterprise services tend to benefit most from Lino.
Lino uses Clean Architecture, separating the system into layers such as Domain, Application, Infrastructure and Presentation.
Yes. Lino encourages domain-based modeling with Entities, Value Objects, Enums, Domain Events and bounded contexts.
Yes. Commands and Queries are separated to facilitate organization, maintenance and scalability of the application.
Yes. The modular monolith is one of the most natural scenarios for Lino, especially when the team wants low operational costs with good internal separation.
Yes. Lino can be used to create modular monoliths, independent services, and microservices-based architectures.
Yes. Lino was designed to reinforce separation of responsibilities, loose coupling, modularity and sustainable code evolution.
Entities represent objects with their own identity within the domain, such as User, Order or Product.
Value Objects represent immutable domain concepts that do not have their own identity, such as Money, Address or Email.
Yes. Lino supports Domain Events to represent relevant events within the domain and maintain low coupling between parts of the system.
The domain can be divided into modules or bounded contexts to reflect distinct business areas, such as catalog, sales, inventory, identity or billing.
Yes. You can start with a few modules and simpler rules and evolve the modeling as the product matures.
Yes. Lino can automatically generate endpoints based on application commands and queries.
Yes. The APIs generated use Minimal APIs of .NET, integrated directly with the application layer.
The generated project is compatible with API documentation via OpenAPI and Swagger, which facilitates contract inspection, testing and integration between teams.
Versioning can follow known REST standards and be combined with organization by endpoints, contracts and builds.
Yes. The Lino architecture allows you to integrate external APIs, webhooks, SDKs and third-party services through the infrastructure layer.
The generated project exposes API contracts through OpenAPI/Swagger, and practical endpoint testing can be supported by HTTP files or similar client tooling according to the selected template and workflow.
Yes. Lino supports the generation of authentication and authorization for frontend and backend projects.
Yes. Lino supports authentication based on JWT for APIs and web applications, with a focus on security and native integration with ASP.NET Core.
Yes. The security model of Lino includes more granular access control with roles, claims and Authorization Policies of ASP.NET Core.
Yes. The frontend can be integrated into the authentication flow for login, token renewal and protected access to pages and APIs.
Lino provides secret commands, such as lino secret list, lino secret set, lino secret remove and lino secret clear, to keep sensitive local values out of versioned files. Generated secrets can also be modeled as Aspire Parameters for publish and deployment flows.
Yes. Generated APIs can start with rate limiting policies for public traffic, authenticated users, API-key routes and temporary token flows, reducing exposure before custom production tuning.
Domain Events represent internal events within the domain. Integration Events are used to communicate modules, services or external systems in a decoupled way.
Yes. Lino supports events for communication between parts of the application and for integration between services when the architecture requires this model.
Yes. When asynchronous messaging is enabled, Lino configures RabbitMQ as the broker so services and modules can exchange messages in a decoupled and resilient way.
Yes. Lino uses MassTransit in messaging scenarios to simplify publishing, consuming and wiring distributed events with the native dependency injection model.
Yes. Lino supports background jobs with Hangfire for scheduled tasks, asynchronous processing, recurring operations and operational visibility through the Hangfire dashboard.
Use domain events for changes inside the domain, integration events for communication across modules or services, queues for asynchronous processing and background jobs for scheduled, recurring or long-running work. For reliable publishing, Lino scenarios use the Outbox Pattern.
Currently Lino supports databases compatible with Entity Framework Core, such as SQL Server and PostgreSQL.
Yes. Data persistence is based on Entity Framework Core for modeling, migrations and database evolution throughout the project life cycle.
Migrations are managed with Entity Framework Core and can be created through lino database migrations add, keeping model changes explicit, versionable and reviewable before deployment.
Not necessarily. In modular monoliths, the most common approach is a shared database with clear organization by module.
In microservices, each service can have its own database when that makes architectural sense.
Yes. Lino supports database evolution with migrations and script-oriented deployment practices, and combines this flow with build and versioning features when services are prepared for release.
Yes. Lino can generate web applications integrated into the backend to accelerate the delivery of complete systems.
Yes. Lino can generate integrated Blazor Web Apps, including frontend resources connected to backend APIs, localization and authentication when those features are selected.
Yes. The Lino architecture does not prevent using React, Angular, Vue or any other frontend that consumes the project's APIs.
Yes. The frontend can work with login, token renewal and consumption of APIs protected by JWT and authorization policies.
Yes. Lino helps to structure pages, components and features in a more standardized way, reducing repetitive decisions on the frontend.
Yes. Lino-generated projects can include structured logging, Aspire dashboard integration, traces, metrics and operational diagnostics to support debugging and production analysis.
Yes. Lino supports cache scenarios with Microsoft HybridCache and distributed cache backed by Redis when that option is enabled, improving consistency across multiple instances.
Yes. By standardizing structure, logs, authentication, APIs and infrastructure, Lino facilitates problem investigation and operational maintenance.
The generated solution can incorporate health checks, metrics, traces, logs and Aspire resource visibility, following the .NET ecosystem practices used by the selected architecture.
Yes. Lino can generate Docker images for services and web applications through the build flow, helping package artifacts for registries and containerized environments.
Yes. The generated projects can be integrated with CI/CD pipelines for build, testing, packaging, migrations and automated deployment.
Build and versioning can follow SemVer-oriented practices, with Lino build support for packaging selected services and web applications as Docker images tagged for release.
Yes. The project can be published in the cloud, containerized environments or own infrastructure, depending on the team's operating strategy.
Yes. Lino accelerates technical setup for deployment in production with Docker, standardized build, persistence, authentication and integration with pipelines.
Lino includes multi-tenant support through lino feature tenant add or lino features tenant add. The generated structure can resolve tenants by domain or slug, apply permissions by context and protect tenant-scoped data.
Shadow entities are local copies of the minimum data a module needs from another context. The lino shadow new command creates the structure, and the corresponding integration event handler should be generated separately with lino event-handler new.
Yes. The roadmap shows continuous evolution and also marks many completed capabilities, such as JWT authentication, Blazor Web Apps, Hangfire, RabbitMQ/MassTransit, migrations, Docker build, HybridCache, multi-language resources, smart merge, secrets and rate limiting.
The completed roadmap includes several core capabilities: .NET/Aspire project generation, modular services, Minimal APIs, SQL Server and PostgreSQL support, background jobs, messaging, JWT security, Blazor Web Apps, Docker build/versioning, user secrets, rate limiting, tenant support and shadow entities.
Code generation, integrations, developer experience, deployment workflows, observability, security hardening and template coverage continue to evolve as the product grows.
You can follow changes on the roadmap page, in the documentation and through the official product channels. Prefer the roadmap status when you need to distinguish completed features from planned improvements.