NeoPolis OS 1.0 "BRNO" LTS
neopolis.tech

NeoPolis OS
the operating system for smart cities

A ready-to-deploy operating layer for municipal digital services. Municipalities bring their data, choose their services, and keep their brand. One operating system serves every surface — mobile app, web app, operator dashboard and REST API. Operational today, not a concept.

Like applications on Android — not modules of a single vendor platform.

7
First-party applications
63
Integrated data adapters
SI + CZ
Live in two countries — all 212 Slovenian municipalities, plus Czechia
5 yr
LTS runtime commitment · 1.0 "Brno"
The structural foundation

Three axioms

Drop any one and the OS collapses into "a platform with extra steps". Each is operational today, not aspirational.

01 · Multi-source

Every data source, one canonical model

Sensors, transit feeds, registries and third-party APIs collapse into Smart Data Models. The municipality stops integrating — it starts publishing.

02 · Multi-vendor

Every solution, one standard API

Any application that uses Smart Data Models runs on NeoPolis OS. No vendor gatekeeping, no exclusive integrations — the city keeps the right to choose vendors year after year.

03 · Multi-city

Every city, one portable architecture

MIMs Plus and Smart Data Models make the whole stack reusable across the EU. Build once in Brno, deploy in Ljubljana, scale to the 190+ OASC cities — the investment is reusable, the lock-in absent.

The problem

Cities deploy mobility in silos

Transit, parking, bike-share, on-demand transport, sensors — each arrives with its own app, its own data and its own dashboard. Citizens juggle multiple apps, operators have no unified view, and data doesn't flow between systems. Building a custom system from scratch takes 12–18 months and significant investment before citizens see any value.

The solution

One operating layer for the whole city

NeoPolis OS connects city data sources through a standardised adapter layer, normalises them into canonical formats, and delivers them to citizens through branded applications. Operators control which services are active through a web-based admin portal. NeoPolis OS is operational today — not a concept, not a prototype.

352API endpoints
16Map layers
13Trip types
2Routing engines (MOTIS · Valhalla)

Coverage. Live across all 212 Slovenian municipalities through national and local data sources, and now in Czechia — national feeds (CHMI air quality, CZPTT rail, PID & KORDIS transit, DATEX II traffic via ŘSD/NDIC) plus Praha and Brno local sources. Poland, Austria and Germany are being assessed for expansion.

What municipalities get

Live in weeks, not years

A national-data app from day one, then progressively deeper local integration — each new connection is one adapter, not a new project.

Day 1

Branded app

A mobile app on the app stores with national transit, weather, traffic, parking and air-quality data. No development needed.

Week 2–4

Configured & live

Operator trained on the admin portal. Services configured, branding set, data-quality monitoring live.

Month 2–6

Local integration

Local systems connected — parking sensors, on-demand transport, events, citizen reports. Each integration is one adapter.

Why NeoPolis OS

Key differentiators

Open data, not vendor dependency

Built on EU standards (GTFS, DATEX II, GBFS, SIRI, NGSI-LD) and open-source routing (MOTIS, Valhalla, MapLibre). No single company can switch off the OS.

Truly multimodal

The trip planner combines private car, public transit, sharing services and park-and-ride in one result — each leg validated against real-time availability.

Dynamic carpooling built in

Drivers share their route; travellers are matched automatically. Rideshare legs appear inside multimodal trip results — not a separate app.

Municipality data sovereignty

Each city is its own tenant — its own data and GDPR controller, no cross-tenant mixing. The municipality owns its data, not the vendor.

Cost-effective on-demand transport

Integrating on-demand services with the trip planner turns expensive door-to-door rides into efficient feeder trips timed to transit connections.

The direction EU regulation is setting

Why centralised platforms cannot follow

A wave of EU regulation is pushing cities toward open, federated, standards-based infrastructure — and away from closed single-vendor platforms. NeoPolis OS is not waiting for that shift to arrive; it is the implementation a municipality can deploy today to comply with the direction the regulation sets.

Regulation, and how NeoPolis OS aligns
EU initiativeWhat it mandates or fundsNeoPolis OS alignment
Digital Europe ProgrammeFunding for common data spaces, including mobilityBusiness model built on this shift
ITS Directive + 2017/1926National Access Points, EU-wide multimodal travel infoConsuming SI + CZ NAPs in production
CEMDSFederated transport data sharing across the EUSC-PAL = data-space connector pattern with provenance
Data Act (2024)Fair data access, interoperability, portabilityOpen standards in, standard formats out — no proprietary lock-in
NAPCOREHarmonising 30+ National Access PointsMulti-country NAP integration operational (SI, CZ)
Interoperable Europe ActCross-border public-service interoperabilityNGSI-LD output, Smart Data Models alignment
EU AI ActTransparency, human oversight and auditability for public-sector AIAuthoritative, provenance-bearing runtime agents can cite — not a black box
Two architectures

The silo vs the federation

The closed centralised platform
  • Scalability bottleneck. Each new city or provider needs a bilateral commercial deal and custom integration.
  • Sovereignty conflict. Cities and PTAs don't want their data locked inside a private platform — and regulation pushes against it.
  • No cross-platform network effects. One aggregator cannot query another's data; each silo is an island.
NeoPolis OS — federated, sovereign, standards-based
  • One adapter, EU-wide. Standard feeds reuse the same code; a new country is largely configuration.
  • Data stays local. Each city runs its own node, its own identity, its own GDPR controller — federation never centralises the data.
  • Every node compounds. Each new deployment adds value for all participants; the network is the moat.
The endgame is a federated mobility query network — Ljubljana, Brno, Vienna, Munich each running their own node with their own data, and a single CityConnect trip request crossing all of them, without any one platform owning the data. The moat is regulatory, not technical: the trust framework is built around sovereignty, not scale — and that is exactly what a centralised aggregator cannot replicate.
Deployment · anti-lock-in

Deployable, not just hosted

The no-lock-in promise is only credible if the OS is genuinely deployable. A SaaS-only product cannot honestly claim "no proprietary runtime" — the runtime would be the lock-in. NeoPolis OS ships in four tiers, with the self-hosted tier as the trust anchor that makes the rest credible.

Four deployment tiers
TierModelBest for
NeoPolis CloudManaged SaaS, multi-tenant, EU regionDefault — small/mid municipalities, fastest onboarding
NeoPolis OS DedicatedSingle-tenant managed instance, EU region of choiceMid/large cities, sovereignty-conscious procurement
NeoPolis OS Self-HostedCustomer-operated, support contractLarge cities, national deployments, sovereignty-mandated tenders
NeoPolis OS FederatedMultiple deployments interconnectedRegional/national rollouts, EU programmes, cross-border services

Cloud is the default; self-hosted is the exit door. Migration tooling is part of the OS, not an add-on — a city can start on Cloud and graduate to dedicated or self-hosted at any time. Even municipalities choosing SaaS feel safer knowing the exit exists; that is what makes "no lock-in" credible rather than rhetorical.

Application delivery · orthogonal to deployment

Four delivery options

Where the deployment tiers decide where the OS runs, the delivery options decide how much of the front-end we deliver — a continuum from "we ship everything" to "you build on the API". A city can pick any tier with any option, and move along the continuum later with no code change on either side.

OptionWhat the city buildsMobility UXTime to launch
A · We deliver everythingNothing — our mobile + web, rebrandedNative, full qualityDays
B · HybridTheir web; our native shell with embedded panels for their custom servicesNative, full qualityWeeks
C · Embed our mobilityTheir own app, embedding our mobility widgetOur widget (WebView / iframe)Months
D · API onlyEverything — they consume the public APIWhatever they buildVariable

A is the default; B answers "but we already have X." The embeddable mobility widget (cityconnect.travel/embed/trip-planner, themed by URL + coordinates) is what keeps Option C in the OS story — the city ships our trip planner under their brand instead of reimplementing it. Throughout, the municipality is the GDPR data controller and we are the processor under a DPA — and the single codebase is never forked per customer.

What the 1.0 LTS commitment covers

The runtime is LTS. Applications follow their own timelines.

The 1.0 "Brno" LTS guarantee — five years of security patches and compatibility — applies to the OS runtime: public APIs, the Keycloak identity layer, the SC-PAL adapter framework, observability, and the operator console. Individual applications carry their own status badge, mirroring the Ubuntu pattern: an LTS kernel with mixed-maturity packages.

ProductionCitizen-facing surfaces fully operational
BetaCitizen surfaces live; operator surfaces maturing
IntegrationAdopted upstream; integration in progress
The catalogue

Deployable applications, from day one

First-party applications use the same public APIs available to every third-party developer. No hidden interfaces, no privileged access. Tap any application for the full buyer and developer brief.

OS capabilities

What the OS does for every city

Always-on foundations included in every NeoPolis OS deployment — not operator-selectable services, but the OS itself. Tap any capability for the full brief.

OS components

The layer beneath the apps

Distinct from citizen applications, OS components are reusable building blocks inside the NeoPolis OS runtime — the business, identity, fare and payment layers that city services draw on rather than reimplement.

Data layer · adapters.neopolis.tech

63 integrated data adapters

Apps consume canonical data; adapters produce it. Every source below is in production through the SC-PAL adapter contract, normalised into the canonical NGSI-LD-aligned model. This is the surface city IT teams configure.

Slovenia is at full production coverage across all 212 municipalities. Czechia is live with national feeds (CHMI air quality, CZPTT rail, DATEX II traffic via ŘSD/NDIC) plus Praha (Golemio) and Brno (KORDIS JMK, data.brno.cz) local sources. Poland, Austria and Germany are being assessed for expansion — most reuse the same GTFS, GBFS, DATEX II and NeTEx patterns, so a new country is largely configuration rather than new code. Internal CityConnect orchestration modules (the multimodal trip planner and the municipality directory) are excluded from this count.

Operator control · data quality

Municipalities control what feeds every app

Adapters feed data layers; data layers feed services. From the operator portal a municipality controls each hop — enabling, disabling and prioritising data sources to manage the quality of its citizen apps. Changes take effect immediately, with no app update.

63Adaptersexternal data sources
toggle · exclude ▸
16Data layersprimary + fallback
enable per tenant ▸
12City serviceswhat citizens use

Layered toggles

Enable or disable independently at three levels — the adapter, the data layer it feeds, and the service that consumes it. Sixteen data layers sit between the data sources and the city services.

Per-source, per-service exclusion

Drop a weak source from one service while keeping it everywhere else — e.g. disable a stale parking feed in trip planning but keep it on the parking map. Quality where it matters, without losing coverage.

Primary + fallback, with circuit breakers

Each layer has a primary source and ranked fallbacks. If a source degrades, the circuit breaker trips and the layer keeps serving from the next source — operator preferences resume automatically on recovery.

Worked example — Parking in Celje
SourceScopeRoleWhat it adds
NAP SiParkNationalPrimary377 facilities nationwide
Brezavta ParkingCelje · KranjFallbackReal-time occupancy for specific cities
Celje Municipal Parking*CeljeFallbackLocal lots via the city's Centralka platform

* Celje Municipal Parking is connected from the city's own Centralka platform — a bring-your-own-data source merged into the national parking service with no app update.

If a source becomes unreliable, the operator disables it for the affected service while the others keep serving — and re-enabling it instantly adds its data back, no code changes or app updates. The operator controls what citizens see; the OS controls how honestly it is labelled — a stale real-time transit feed is automatically shown as "scheduled only".

Six-dimension quality framework

Not "is it connected?" but "is it good enough for my citizens?"

AvailabilityIs the source reachable? Down → auto-fallback; the circuit breaker protects the OS.
FreshnessHow old is the latest data, graded A–D against the source's expected update interval.
CompletenessDoes it actually cover this municipality? Scope badges show national / regional / city.
FormatStandard (GTFS, DATEX II, GBFS) integrates with zero custom code; proprietary gets an adapter.
LicenseOpen data (CC0, CC-BY) or contract-required — governs which tenants may use the source.
ReliabilityHistorical uptime, success rate, latency percentiles and error distribution over time.
Freshness grades A · FreshB · AcceptableC · WarningD · Stale "Better no data than bad data" — a Grade-D source can be dropped from a service so citizens never see stale information.
For developers & integrators

Two ecosystems, one OS

Any application that uses Smart Data Models runs on NeoPolis OS without further integration. Apps consume canonical data; adapters produce it. Both are external surfaces of the same OS.

Building an app for NeoPolis OS?

Browse live NGSI-LD entity types in CityData, copy a subscription snippet, and integrate in minutes. First-party and third-party apps speak the same public APIs — Optifarm's OFP and BusinessCore are the first partner entries in the catalogue.

apps@neopolis.tech →

Two parallel registries

Most cities run 5–15 apps and 20–80 adapters. The catalogue is what citizens see; the adapter registry is what city IT configures.

apps.neopolis.techApplication catalogue — apps that run on the OS
adapters.neopolis.techAdapter registry — Standard, National & Local data sources
See all 63 integrated adapters ↓
Open-source pipeline

The multi-vendor claim, demonstrated

Grafana ships as the first live open-source integration at launch. A pipeline of further candidates is under evaluation for 1.1+ — no single project's vitality is a launch dependency.

Decidimv1.1 candidate

Participatory democracy (CityParticipate category). Barcelona-led, strong active community in 2025–2026; Mediterranean-EU credibility.

FROST-Servercandidate

OGC SensorThings reference implementation, actively maintained by Fraunhofer IOSB.

FixMyStreetcandidate

Citizen reporting (CityReport). Maintained by mySociety; actively developed.

Snap4City Dashboardsunder evaluation

"Powered by FIWARE" certified, H2020-era project. Codebase and city deployments verifiable; community activity modest after the H2020 cycle.

Built on FIWARE

A distribution, not a fork

NeoPolis OS is built around the FIWARE reference architecture and Smart Data Models — the same kind of relationship a Linux distribution has to the upstream project. We take the open standards and reference design and deliver them as an opinionated, production-tested distribution: EU residency, pre-built Central-European adapters, a commercial SLA and a five-year LTS commitment. Our APIs already emit NGSI-LD-aligned entities; native context-broker federation is on the 1.x roadmap. Aligning with FIWARE is a foundation we build on, not a box we tick.

NeoPolis OS sits at the intersection of three EU initiatives: we implement FIWARE's technical reference architecture, we conform to OASC's MIMs Plus interoperability principles, and we are designed to participate in Gaia-X data spaces. None of the three, alone, delivers a deployable product to a municipality. NeoPolis OS does — without compromising alignment with any of them. FIWARE = the kernel · OASC = what cities want · Gaia-X = the trust framework above
Standards & compliance

EU standards, compliant by design

ITS DirectiveINSPIRENGSI-LDFIWARELiving-in.EU MIMsCitiverse EDICDS4SSCCIPCEI CoreAI OpsKeycloak (OIDC/SAML)eIDAS 2.0 / SI-PASS readyISO 27001GDPR by designAI Act compliant
Technology

Open foundations, no lock-in

React NativeNext.jsNestJSKeycloakMOTIS + ValhallaMapLibre + MapTilerPython / FastAPIPostgreSQLMQTT
Standards catalogue

The standards the OS speaks

EU-mandated and industry formats integrate with zero custom code, and the same adapter works in any member state — a new country connects to its National Access Point rather than needing new code. Proprietary sources get one adapter to the same canonical model, and municipal IoT sensors add hyperlocal granularity on top of national data through the same pipeline.

Public transport
GTFSGTFS-RTSIRINeTExOJP (CEN/TS 17118)GTFS-FlexGOFS
Roads & traffic
DATEX II eventsroadworkstravel timesroad weatherFCD / countersparking
Shared & EV mobility
GBFSOCPI (EV charging)
IoT & sensors
MQTTOGC SensorThingscanonical sensor modelNGSI-LD output
EU interoperability
NGSI-LDFIWARE Smart Data ModelsLiving-in.EU MIMs 1–6
Access & geospatial
National Access PointsITS DirectiveINSPIRE