# Kiwi.com Orbit: React Components and Tailwind Setup > Orbit is Kiwi.com's TypeScript React component library, distributed mainly through @kiwicom/orbit-components and designed to give product teams a consistent interface vocabulary. Its main adoption constraint is that consumers must configure Tailwind CSS correctly and account for Orbit's package structure. **kiwicom/orbit** — React components of open-source Orbit design system by Kiwi.com - Repository: https://github.com/kiwicom/orbit - Website: https://orbit.kiwi - Stars: 1,439 · Forks: 174 - Language: TypeScript - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/kiwicom-orbit ## Why Kiwi.com Orbit Exists Orbit addresses product-interface consistency across Kiwi.com. Its components are React building blocks for the company's products, and the repository description identifies the package as the open-source Orbit design system. That positioning matters because a component library is more than a collection of visible controls. It establishes decisions about composition, interaction patterns, visual tokens, typography, and accessibility behavior that would otherwise be repeated by separate product teams. The primary audience is developers building React products, particularly teams that want to follow the design conventions already used at Kiwi.com. The README gives the library's stated purpose directly: it provides developers with a straightforward way to build Kiwi.com products. That makes Orbit a closer fit for an existing React application seeking a prescribed system than for a project that only needs a small utility component. Orbit is broader than the npm component package alone. Repository entries under `packages/`, workspace scripts, and commands such as `components`, `tailwind-preset`, `tokens`, and `themer` show a monorepo containing several related packages. The distribution also includes component documentation, icons, right-to-left support, and theming documentation. Consumers therefore need to decide whether they want only `@kiwicom/orbit-components` or whether their integration also depends on related packages such as `@kiwicom/orbit-tailwind-preset`. The repository is not archived, and the last push was on 2026-07-06. Recent release records include stable version `27.7.0` and an alpha release of `27.7.1`, so release-channel selection is part of the practical adoption decision. The alpha designation should not be treated as equivalent to the stable package for production use. ## How Orbit Packages Reach a React Application The public entry point for application developers is `@kiwicom/orbit-components`. Imports are made from package subpaths such as `@kiwicom/orbit-components/lib/Alert`, rather than through a single documented aggregate import. This package structure can affect application bundlers, dependency policies, and component-loading choices, so a migration should inspect the existing resolver configuration before changing imports. Styling is more involved than installing the package. The README states that Orbit uses Tailwind CSS and that Tailwind must be present in the consuming project for components to appear correctly styled. It also identifies `@kiwicom/orbit-tailwind-preset` as the package containing the Tailwind configuration used by Orbit. The root package uses Yarn workspaces and Lerna, while its build pipeline builds design tokens, the Tailwind preset, and components in sequence. That repository structure suggests a token-to-preset-to-component pipeline, although the README does not describe the internals of token generation. It is safe to identify the packages and scripts, but not to claim details about build caching, class generation, or runtime style injection that are not documented. What is confirmed is that Tailwind participates in producing the styles consumed by the component package. Custom themes add another layer. The documented mechanism is to wrap the application in ``. The README refers to a separate `OrbitProvider` document for details, so teams should not assume that installing the package alone activates project-specific theming. Theme customization and the base component installation are separate integration decisions. ## Installing Orbit and Rendering the First Alert The documented consumer installation is available through npm or Yarn. Use the package manager already enforced by the application repository rather than mixing lockfiles. Both commands below are taken directly from the README. ```bash npm install @kiwicom/orbit-components ``` After it completes, Orbit components also expect Roboto fonts. The following stylesheet link is the README's HTML example. Place it where the application loads its global styles or document head assets. ```html ``` The component can then be imported from its documented package path. The following block contains JSX, so a JavaScript fence is used. ```js import Alert from "@kiwicom/orbit-components/lib/Alert"; Hello World!; ``` A successful render should display the `Alert` content with Orbit's intended styling. If the component appears without its expected appearance, check Tailwind installation and the Orbit preset first because the README explicitly says Tailwind must be installed for correct styling. If the application uses a custom theme, it also needs the provider configuration documented under `packages/orbit-components/src/OrbitProvider/README.md`. The README does not provide a complete application bootstrap, provider configuration, Tailwind file, bundler settings, or a universal test command for consumers. Those details must come from the project's official documentation or the target application's build setup rather than being inferred from the basic example. ## Tailwind, Fonts, and Theme Boundaries Orbit's dependencies extend beyond React itself. Tailwind CSS is required for components to be styled correctly, Roboto font resources must be loaded, and `@kiwicom/orbit-tailwind-preset` supplies the Tailwind configuration used by Orbit. These requirements make installation a compatibility decision rather than a one-line dependency addition. Tailwind configuration is the most obvious integration boundary. The README names the preset package but does not include a complete consumer `tailwind.config` example. A developer therefore cannot reconstruct the required host configuration from the README alone. Official Orbit documentation is the stated place to find that setup. If an application already has a conflicting Tailwind architecture, verify compatibility before replacing or extending it. Font loading is explicit. The documented Roboto stylesheet can be added as HTML or CSS. Teams with content-security policies, self-hosted font rules, or a requirement to avoid external Google Fonts requests must account for those application constraints. The README offers the link and import forms, but it does not describe font hosting, fallback behavior, or synchronization with Kiwi.com's internal asset policy. Theming is supported through ``, but the main README does not enumerate theme properties or show a provider configuration. This is a meaningful documentation boundary for design-system adopters. Anyone expecting to reproduce an exact product theme needs the dedicated provider documentation and should compare it with the application's existing global CSS and token setup before coding. ## Where Orbit Is the Wrong Choice Orbit is a poor fit for a project that cannot accept Tailwind-based styling. Its own documentation makes Tailwind mandatory for correct component appearance, so wrapping the package around a deliberately incompatible styling architecture would add friction without preserving the intended result. A lightweight component with no dependency on Orbit's Tailwind setup would be easier to own in that case. It is also a questionable choice for a non-React application. The package is specifically a React component library written primarily in TypeScript. Consumers would need to build a compatibility layer before using it, and no such integration is documented here. Release stability creates another boundary. The listed stable package release is `@kiwicom/orbit-components@27.7.0`, while the newer listed entry is `27.7.1-alpha.0`. Production teams that require a conservative upgrade policy should distinguish those channels. The repository does not document the scope of the alpha changes, compatibility guarantees, migration notes for that specific version, or the project's release policy in the main README. Finally, Orbit cannot be evaluated as a generic replacement for every component system. Its README positions it around Kiwi.com products and their interface conventions. A team with no interest in those conventions may find that adopting the package creates product vocabulary that must be adapted later. ## Bespoke React Components as the Alternative The real alternative is not another named vendor library that is absent from the repository documentation. It is a bespoke React component layer maintained by the consuming team. This approach starts from the application's own screens, accessibility requirements, state model, and CSS strategy, then implements only the controls that product actually needs. A bespoke layer offers closer control over dependency boundaries and release frequency. It can use the application's existing design tokens and styling architecture without introducing `@kiwicom/orbit-tailwind-preset` or Orbit's provider model. That can be preferable for a small product with a narrow component surface. The trade-off is that the team must own interaction states, visual regressions, documentation, type declarations, and consistency across products. Orbit makes a different exchange. Consumers gain an existing Kiwi.com-oriented component vocabulary, TypeScript definitions, documented patterns, icons, right-to-left resources, and theming support. They accept Tailwind setup, package-specific imports, and some reliance on Orbit's release cadence. The choice is therefore between shared system cost and local ownership, not between two identical implementations. For an organization already using Orbit conventions, bespoke controls are likely to be the wrong choice because they may fragment the interface. For a small React application with incompatible infrastructure, local components may be less expensive despite the maintenance burden. ## Maintenance, Releases, and the MIT License The repository is not archived, and its last push was on 2026-07-06. The release list shows `@kiwicom/orbit-components@27.7.0` dated 2025-10-31 and `@kiwicom/orbit-components@27.7.1-alpha.0` dated 2025-11-25. Consumers who need predictable production behavior can pin a selected version and read its package documentation before upgrading. Upgrade cost depends on more than React compatibility. A consumer may need to check changes to Tailwind configuration, provider setup, component props, and whether a chosen package is stable or prerelease. The repository has checks for types, links, CSS, and statuses, plus a component size script, but the README does not provide a consumer migration guide for Orbit version 27. The repository declares the MIT license. That identifier is relevant when reviewing permitted use, modification, distribution, and notice obligations, but the exact `LICENSE` file should be the authority for those terms. The license also does not remove the operational need to track package updates, test component behavior, and account for external font and Tailwind configuration. The README says the project is still working toward being fully open source and welcomes bug reports and feature requests through its issue templates. That wording deserves attention when evaluating contribution expectations, although it does not by itself specify a deprecation timeline. ## Conclusion Adopt Orbit when a React product team wants Kiwi.com's component vocabulary and can absorb its Tailwind, font, theme, and package-integration requirements. Do not adopt it if a self-contained component package is essential or if the latest desired component changes require accepting prerelease packages. Before migration, verify Tailwind rendering with the documented Roboto font setup, inspect the `OrbitProvider` integration needed for a custom theme, and review `LICENSE` plus the release channel you intend to pin. ## FAQ ### How do I install Kiwi.com Orbit in a React project? Install `@kiwicom/orbit-components` with `npm install @kiwicom/orbit-components` or `yarn add @kiwicom/orbit-components`. The consuming project must also have Tailwind CSS configured for components to render with the intended styles. ### Does Kiwi.com Orbit require Tailwind CSS and Roboto? The README states that Tailwind must be installed for Orbit components to be styled correctly. It also instructs consumers to load the Roboto font weights and styles through the documented Google Fonts link or CSS import. ### Can I use a custom theme with Kiwi.com Orbit? The README says a custom theme requires wrapping the application in ``. Detailed provider configuration is not included in the main README and is directed to the `OrbitProvider` documentation. ### Which Kiwi.com Orbit package should I use for application development? The documented application package is `@kiwicom/orbit-components`. Separate packages cover concerns such as the Tailwind preset, design tokens, theming, and tracking, but the README does not say that every consumer must install all of them. ## Sources - [kiwicom/orbit on GitHub](https://github.com/kiwicom/orbit) - [License: MIT](https://github.com/kiwicom/orbit/blob/master/LICENSE) - [Project website](https://orbit.kiwi) - [README](https://github.com/kiwicom/orbit/blob/master/README.md) - [Releases](https://github.com/kiwicom/orbit/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kiwicom-orbit