One community system for the whole port city
Your port is a city of terminals, truckers, shipping lines, forwarders, customs and rail. DMS connects them on the same data, with an open-source Port Community System at the core.
The code is open: your port reads it, audits it and runs it at home, and no new monopoly owns its data. Every feature a PCS needs, in one platform · 17 bricks, 16 open and 1 kept by DMS · 824 modules in 147 applications already written (measured on 18/10/2026).
Six sentences for a port director
- Terminals, truckers, shipping lines, forwarders, customs and rail work on the same data, in one community system for the port city.
- It is built from software already in service in ports: truck appointments (VBS) and the automated gate (GOS).
- The code is open: your port reads it, audits it and runs it in the cloud or on its own servers, with no new monopoly on its data.
- Each actor decides, data item by data item, who reads what; every read is signed and visible to the owner.
- The port authority announces, the community governs the roadmap, each terminal keeps its own business rules.
- DMS installs and runs it, with no setup fee: the subscription starts on the first day of connection.
What DMS brings to you
- DMS PCS, open source · the Port Community System we are building from code already in production: community and identity, vessel call, declarations and single window, customs, truck-barge-rail appointments, gate and OCR, container status, booking-release-eBL, EDI hub, payments, empties and swap, data sharing, the authority cockpit, carbon, public API, public portal and orchestrator (in development) · all our open-source projects
- Regional VBS · one truck appointment for every terminal of the city, with the PCS (coming)
- CO₂ monitor · port emissions, terminal by terminal
- SwapContainer · container swaps between the actors of the city
The port community systems that exist today
17 systems compared from public information, to be verified with each operator. Names are trademarks of their owners, shown only to identify each system.
| PCS | Port · country | Governance | Open code | Functions | What we learn |
|---|---|---|---|---|---|
| Portbase | Rotterdam · Amsterdam · Netherlands | not-for-profit organisation backed by the port authorities | No | vessel call notification · declarations · manifests · truck/barge/rail appointments · container status | a PCS backed by the port earns the trust of the whole community |
| DAKOSY | Hamburg · Germany | company owned by port players | No | community EDI · export/import customs · container status · transit | customs EDI is the backbone that makes a PCS indispensable |
| SOGET S)ONE | Le Havre · French ports · France | private company | No | port single window · customs · manifests · cargo status | the customs link creates the value — the rest plugs in around it |
| MGI Ci5 | French Mediterranean ports · France | private company of the port community | No | cargo tracking · customs · port community data | a PCS tracking feed is worth most when third-party applications can read it |
| PORTNET | Singapore · Singapore | run by the port ecosystem | No | vessel call · port services · billing · status | a PCS that bills port services becomes the counter for every payment |
| Valenciaport PCS | Spanish Mediterranean ports · Spain | port authority foundation | No | vessel calls · cargo · inland transport · data | a port authority can fund a PCS as a common good |
| Portic | Barcelona · Spain | port community company | No | EDI · transport orders · status | the local community wants to keep control of its data |
| Destin8 (MCP) | Felixstowe · UK ports · United Kingdom | private company | No | customs · container status · payments | after Brexit the customs link made usage explode |
| Port Optimizer | Los Angeles · United States | driven by the port with an industrial partner | No | supply-chain data visibility · arrival forecasts | a port data portal without integrated appointments leaves a gap — the place of a VBS |
| NxtPort | Antwerp · Belgium | community data platform | No | data sharing · APIs · data marketplace | data sharing only takes off if everyone keeps control of their rights |
| dbh Logistics IT | Bremen · Germany | private company | No | EDI · customs · status | historical PCSs are EDI integrators |
| Kale Logistics | several ports and airports · India | private company | No | SaaS PCS · documents · payments | multi-port SaaS already exists on the air side — not open source |
| Maqta Gateway | Abu Dhabi · United Arab Emirates | subsidiary of the port group | No | single window · payments · services | a PCS backed by the port group moves fast but does not export |
| Port-MIS | Korean ports · South Korea | public administration | No | vessel calls · declarations · statistics | the regulatory side is first a matter of state (national single window) |
| eModal | US ports · United States | private company | No | trucker community portal · appointments · fee payments | in the US truckers pay their fees through a single portal — an established habit |
| TradeLens | global · — | consortium of a carrier and a software vendor (discontinued) | No | document sharing · blockchain | a platform backed by one carrier did not convince its competitors — neutrality matters more than technology |
| US public PCS initiative | US ports · United States | public funding · open-source publication announced | announced | common PCS for ports | the only other open-source initiative we know of |
What the benchmark tells us
None of these systems is open source: a port can neither read the code nor run it at home, and each installation is a project of its own. Hence our answer: one all-in-one platform, made of open bricks and plugins, that each port installs, audits and extends.
What is missing everywhere
Seven gaps shared by the port community systems of the benchmark. No system is named: these are gaps of the category, not of one product.
No one is open source
A port can neither audit the code nor run it itself.
Costs: audit · With an open PCS: sovereignty
The truck is forgotten
Historical PCSs were born from EDI and customs. Truck appointments, the gate and empty swaps are add-ons; here they are the core.
Costs: congestion · With an open PCS: shorter queues
Integrators, not products
Every installation is a custom project. Nobody installs in five minutes.
Costs: time to start · With an open PCS: install in minutes
Captive data
Players hesitate to share because they cannot see who reads what. A signed log and consent per data item remove that brake.
Costs: trust · With an open PCS: data that flows
One port at a time
A trucker working in two ports has two accounts and two interfaces. Federation between ports does not exist in these systems.
Costs: double work · With an open PCS: one account
Carbon is missing
Avoided trips and modal shift are not counted, while port authorities must report them.
Costs: reporting · With an open PCS: savings counted with the GLEC framework and ISO 14083
Local terminals pay twice
A terminal buys an appointment system, then a gate system, then a portal. With appointments (VBS) and gate (GOS) inside the PCS, local terminals save those purchases.
Costs: cost of tools · With an open PCS: all in one
What each port community system covers
| PCS | Vessel call | Declarations | Customs | Truck appointments | Gate · OCR | Container status | Payments | Data sharing | Empties · swap | Open code |
|---|---|---|---|---|---|---|---|---|---|---|
| Portbase | ● | ● | ● | ● | ○ | ● | ? | ◐ | ? | ○ |
| DAKOSY | ? | ● | ● | ? | ○ | ● | ? | ◐ | ? | ○ |
| SOGET S)ONE | ● | ● | ● | ? | ○ | ● | ? | ◐ | ? | ○ |
| MGI Ci5 | ? | ● | ● | ? | ○ | ● | ? | ◐ | ? | ○ |
| PORTNET | ● | ◐ | ? | ? | ○ | ● | ● | ◐ | ? | ○ |
| Valenciaport PCS | ● | ● | ? | ◐ | ○ | ● | ? | ◐ | ? | ○ |
| Portic | ? | ◐ | ? | ◐ | ○ | ● | ? | ◐ | ? | ○ |
| Destin8 (MCP) | ? | ◐ | ● | ? | ○ | ● | ● | ◐ | ? | ○ |
| Port Optimizer | ◐ | ○ | ○ | ○ | ○ | ● | ○ | ● | ? | ○ |
| NxtPort | ○ | ○ | ○ | ○ | ○ | ◐ | ○ | ● | ? | ○ |
| eModal | ○ | ○ | ○ | ● | ○ | ● | ● | ◐ | ? | ○ |
| DMS open-source PCS | ○ | ○ | ◐ | ● | ● | ● | ● | ◐ | ● | ● |
● yes · ◐ partly · ○ no · ? not known. Other systems: public information, to be verified with each operator. Our row: ● runs today, ◐ being adapted, ○ to build.
Where we differ
Some of these are not in the PCS specifications yet: they come from the software DMS already runs in ports.
Truck appointments at the core
Slots, quotas per block and waiting lists are the heart of the platform, not an add-on to customs EDI.
A community of thousands
Truckers, dispatchers and drivers handled every day, with their own accounts and roles per port.
Gate with OCR
Plates and containers read at the gate, the appointment checked in seconds, the EIR issued on the spot.
Empty swaps
A trucker returning an empty is matched with one looking for an empty: two trips become one.
Rating of every player
Each organisation is rated on what it really does (punctuality, no-shows, turn times), in the manner of ride-hailing apps.
Turn time per truck
The time spent in the terminal is measured from gate in to gate out, per truck and per company.
Feature by feature: all there
48 functions a port community system needs, brick by brick. 26 are already in the DMS code, 16 need adapting, 6 are still to build. A link opens the public product page when one exists; the others are described in the bricks below.
Community and identity
accounts · organisations · roles · permissions (in the code)
one organisation present in several ports (federation) (to adapt)
two-factor login · magic link (in the code)
access card · TWIC (in the code)
Vessel call
vessel call schedule (in the code)
vessel visit and berth operations (in the code)
stowage plan (BAPLIE) (to adapt)
arrival notification and FAL forms (to build)
port dues · pilotage · towage · mooring (to build)
Declarations and single window
import/export cargo manifest (to build)
national maritime single window connector (to build)
dangerous goods declaration (to adapt)
Customs
customs holds and releases (to adapt)
customs exam and scanning (to adapt)
national customs connectors (to build)
Truck · barge · rail appointments
truck appointment by slot and quota (in the code)
one portal for several terminals (to adapt)
waiting list · transfers · delay requests (in the code)
barge and rail appointments (to adapt)
Gate and OCR
automated gate · OCR · plate reading · barriers (in the code)
EIR · equipment interchange receipt (in the code)
weighing · seals · reefers (in the code)
Container status
container status and history (in the code)
subscription to a container’s events (in the code)
vessel GPS tracking (to adapt)
Booking and release
booking · release · delivery order (to adapt)
letter of guarantee (in the code)
electronic bill of lading (eBL) (to build)
EDI and connectors
carrier EDI hub (in the code)
railway operator APIs (in the code)
TOS connectors (in the code)
Payment and billing
billing · invoices · receipts (in the code)
card payment · prepaid wallet (in the code)
gate fees · penalties · peak pricing (in the code)
connection to the accounting ERP (to adapt)
Notifications
email notifications · messaging · chat (in the code)
Empty containers
empty container exchange between truckers (in the code)
empty return rules · depots (to adapt)
Forwarders
forwarder portal · files · documents (to adapt)
Data sharing
consent and data sharing between players (to adapt)
audit log of every exchange (in the code)
Port authority
port authority cockpit · congestion (to adapt)
modal shift · intermodal (in the code)
Carbon
carbon footprint per trip and per terminal (in the code)
API
public API · service keys · logs (to adapt)
connector for AI agents (in the code)
Support
support · SLA · tickets (in the code)
Public portal
public customer portal (to adapt)
« in the code » means the function exists in DMS today, not that every port can switch it on yet. Statuses as of 23/10/2026.
The 17 bricks of the PCS
Each brick is a sub-application a port installs as it needs. 16 are open; the orchestrator stays with DMS. The status says where each brick stands today: « in development » means its tables, lists and screens exist and are tested, not yet its functions.
Community and identity
one account per person · one record per organisation · roles per port · federation between ports
Code: open · Status: in development
Vessel call
from arrival notice to departure: ETA · berth · operations · FAL forms · port dues
Code: open · Status: in development
Declarations and single window
manifests · dangerous goods · submission to the national maritime single window
Code: open · Status: in development
Customs
holds · releases · exams · customs status visible to the trucker
Code: open · one connector per country · Status: in development
Truck · barge · rail appointments
the DMS VBS as a brick: slots · quotas · multi-terminal · waiting list
Code: open (core) · models closed · Status: first version
Gate and OCR
the DMS GOS as a brick: OCR · plate reading · barriers · EIR · weighing
Code: open (core) · models closed · Status: in development
Container status and subscriptions
one single view of the container · its events · its subscribers
Code: open · Status: in development
Booking · release · eBL
from booking to delivery order · letters of guarantee · electronic bill of lading
Code: open · Status: in development
EDI hub and connectors
one translator from EDIFACT · API · CSV to the common model · TOS and rail connectors
Code: open · Status: in development
Payments and billing
gate fees · penalties · port services · prepaid wallet · ERP link
Code: open · Status: in development
Empties and swap
return rules · depots · empty exchange between truckers (ContainerSwap)
Code: open (marketplace) · matching engine closed · Status: in development
Data sharing and consent
who sees what · consent per data item · log of every read · data-space connector
Code: open · Status: in development
Port authority cockpit
congestion · avoided trips · modal shift · carbon · control-room screens
Code: open (screens) · forecasts closed · Status: in development
Carbon
emissions per trip · per terminal · per trucker · gains from swaps
Code: open · Status: in development
Public API and agents
a documented API · keys per organisation · a connector for AI agents
Code: open · Status: in development
Public portal
the community website: tracking · appointments · documents · support
Code: open · Status: planned
Orchestrator and models
the models that decide: quotas · forecasts · resource planning · business rules
Code: closed · two patents filed · Status: in development
Statuses as of 20/10/2026, updated as each brick is delivered.
What already runs
The PCS is not a project starting from zero: it reuses the parts of the DMS platform that are written and, for most of them, in service today.
VBS · truck appointments
37 modules · in production
GOS · gate and OCR
141 modules · in production
Core platform
67 modules · organisations, slots, vessel calls, data pipelines
Identity and federation
18 modules · single sign-on, roles per port
Intermodal · barge · rail
32 modules · transport plans, forecasts
Empties and swap
41 modules · matching empty containers
Billing
14 modules · invoices, payments, wallet
EDI hub
4 modules and 22 carrier connectors · carrier messages
Carbon
code written · emissions per trip, not yet in service
AI agents
13 modules · connector for AI assistants
Support
10 modules · tickets and service levels
Customer portal
a web portal · in production
When the code was written
| Area of the code | Modules | First → last month written |
|---|---|---|
| Api | 3 | 05/2025 → 07/2025 |
| Appointment | 10 | 05/2025 → 02/2026 |
| Authority | 5 | 05/2025 → 02/2026 |
| Booking | 5 | 05/2025 → 04/2026 |
| Carbon | 4 | 05/2025 → 10/2026 |
| Edi | 9 | 05/2025 → 08/2026 |
| Empties | 3 | 05/2025 → 12/2025 |
| Gate | 10 | 05/2025 → 08/2026 |
| Identity | 11 | 05/2025 → 09/2026 |
| Notifications | 3 | 05/2025 → 10/2025 |
| Payment | 8 | 05/2025 → 04/2026 |
| Status | 4 | 05/2025 → 05/2026 |
| Support | 2 | 05/2025 → 05/2026 |
| Vessel call | 7 | 05/2025 → 02/2026 |
| Data | 5 | 10/2025 → 09/2026 |
| Customs | 4 | 02/2026 → 02/2026 |
| Declarations | 2 | 02/2026 → 02/2026 |
| Forwarders | 1 | 09/2026 → 09/2026 |
Dates from the first commit of each module in git, measured on 18/10/2026.
How it works
1
2
3
The connectors are given away too
The connectors to terminal operating systems, EDI and OCR cameras are part of the open code: an integration starts from a connector that already works, not from a blank page.
Already connected: the terminal operating systems most used in container terminals, in several versions each, and more as ports join.
TOS connectors, both ways
Read vessel calls, container status and holds from the terminal operating system; write appointments and gate transactions back. One connector per TOS and per version.
A modular ETL
One sub-module per TOS, the same common model at the output. Adding a terminal means adding a sub-module, not rewriting the pipeline.
The OCR API contract
The contract our gate uses with OCR cameras, with its JSON collection: any OCR vendor plugs in by following it.
Safer because open
Code that everyone can read is code that everyone can audit.
Code anyone can read
Anyone can audit the core. A flaw is reported through a public security policy, fixed in public, published with its date.
One instance per port
A port’s data never sits next to another port’s. Federation shares identity and empties, never operational data.
On premises possible
The same installer runs behind the port’s VPN, on its own servers. DMS has already installed on premises at a terminal.
Least privilege
Roles per port and per organisation · two-factor login · API keys per organisation, revocable.
Signed log
Every read of someone else’s data is traced: who, what, when. The data owner sees it.
Service targets
| What | Target | Note |
|---|---|---|
| Core availability (cloud) | 99.9 % per month | proposed target · on premises: depends on the port infrastructure |
| Read API response | < 500 ms (95th percentile) | proposed target |
| EDI message translation | < 1 min end to end | proposed target |
| Gate decision on an appointment | < 2 s | proposed target |
| Retention of the data-access log | per the port’s law (at least 1 year proposed) | proposed target · to agree with each authority |
| Critical security fix published | < 72 h after report | proposed target |
These are proposed targets, agreed with each port; they are not measured guarantees.
The standards the PCS speaks
A PCS is worth the messages it understands. Each standard is tied to a brick.
| Standard | Use | Brick |
|---|---|---|
| UN/EDIFACT | BAPLIE · CUSCAR · CODECO · COARRI · COPARN · IFTDGN | EDI hub · Vessel call · Declarations |
| IMO FAL · ISO 28005 | vessel call forms, ship-to-port electronic exchange | Vessel call |
| EMSWe (European Union) | European maritime single window | Declarations |
| DCSA | Track & Trace · Booking · eBL | Container status · Booking |
| ISO 6346 | container identification | Gate · Status |
| IMDG | dangerous goods | Declarations · Gate |
| GLEC · ISO 14083 | transport emissions calculation | Carbon |
| OpenAPI · MCP | public API · AI-agent connection | API |
| IDSA · Gaia-X | sovereign data spaces | Data sharing |
DMS is a member of TIC 4.0, the initiative that standardises terminal operations data.
One instance per port, cloud or on premises
The open core runs at the port; the DMS orchestrator is called through an API; federation links the ports.
Port A · one instance
The open PCS core and the port’s own database. Nothing is shared with another port’s instance.
Port B · one instance
Same core, its own database, its own rules. Each port decides when it updates.
On premises · behind the port VPN
The same core and a local database on the port’s own servers, when the data must not leave them.
Around each instance
- Federation: identity and empties shared between ports, never operational data
- DMS orchestrator: called through an API for the closed models and business rules; the core never depends on it
- Terminal operating systems: feed each instance through the connectors
- National single windows: declarations exchanged with each instance
How the public repository will be organised
open-pcs/ ├── core/ shared core ├── modules/ 16 open bricks ├── connectors/ TOS · carriers · customs · single windows ├── installers/ docker · cloud · on-prem ├── docs/ specs · UML · guides └── tests/
One brick = one module = one main table. The core never depends on the orchestrator: without it, each brick keeps simple rules. The repository opens once the code is ready and scanned for secrets.
The code is free, the API is billed
Software as we knew it is gone. Well-orchestrated AI agents now write, test and ship code, and DMS works that way: agents build, people set the business rules and decide the go-live. When code costs this little to write, it is no longer what a port should pay for.
So we open it. A port, its integrators and its community read the code, audit it and run it, in the cloud or on their own servers. Open code is safer code: anyone can check what it does. It frees a port from lock-in: no single supplier holds its data or its integrations. And it lets everyone move faster, because a port that needs a feature can build it on the same bricks as everyone else.
The code is open
On premises or in the cloud: any port downloads it, reads it, runs it.
The setup is offered
DMS installs the platform and runs it for the port, with no setup fee.
The subscription starts on day one
From the first connection, even with a single user: the API and the data behind it.
Open
- the code of the appointment system (VBS), the gate system (GOS) and the PCS bricks
- the TOS, EDI and customs connectors
- the cloud and on-premises installers
- the documentation, the UML and the tests
At DMS
- the AI models: quotas, forecasts, turn times, resource planning, orchestration
- the business rules configured for each terminal and each port
- installing, operating, supervising and optimising each installation
- the subscription to the API and to the data behind it
The models and the business rules behind them are ours, protected by our patents, and they are not licensed with the open code.
Compared with open-core companies
| Company | Free | Not free | What we keep from it |
|---|---|---|---|
| Red Hat | the full system | support, maintenance, certification | the software is free, trust is the product |
| GitLab | the community edition | enterprise features, hosting | the boundary must be clear and written |
| Odoo | the community edition | enterprise edition, hosting | openness brings partner integrators |
| Mattermost | the server | compliance, large teams | sovereignty matters to the public sector |
| Elastic | the engine | managed services, advanced features | a too-permissive license lets a large cloud resell the product |
The port keeps its data, on the infrastructure it chooses. A repository is linked from this page only once it is public, and each brick shows its real status: « in development » until its functions are written and tested.
With the port authorities
The PCS is a common good of the port: the authority announces it, the community governs it, DMS builds it.
The port announces, DMS builds
A joint letter in which the port authority announces the deployment; DMS commits through its CEO. If the port prefers, the letter can come from DMS.
A community board
Terminals, truckers, forwarders, carriers, customs: one seat each to prioritise the public roadmap.
Data rules voted
The board sets the default sharing rules; each data owner can be stricter, never looser.
Open contributions
Every contribution goes through review and tests. DMS maintains the core.
Each rule above is a proposal, agreed with each port before it applies.
How a port works with us
Who brings what. A starting point to discuss with each port, not a contract.
The port authority
the port, its community, the governance and the public mandate
Partners who know the ports
introductions, funding paths, the first pilot port
DMS
the code (appointments, gate, core), the team and its AI agents, installation and operation
The port community
priorities, feedback, contributions
From a first call to a first port
What is true today, then the order of what follows. No date is promised: each step is set with the port.
| When | What |
|---|---|
| Today | The bricks of the appointment system (VBS) and the gate system (GOS) are opened one by one; each shows its real status, « in development » until its functions are written and tested. |
| Today | This page: what the open-source PCS is, how it is built and how it is governed. |
| Next | A first pilot port: vessel call, declarations and customs connectors configured with the port. |
| Then | The port authority cockpit and data sharing between the members of the port community. |
| Then | Federation between ports: shared identity and empties, never operational data. |
What could go wrong, and the answer
A port authority choosing an open platform should know where it can fail. Here are the six risks we see, and what we do about each one.
A large player takes the code and resells it
Our answer: strong-reciprocity license for the core (AGPL proposed) · registered trademark
Likelihood: 30 % (our estimate) · Response: reduce
Customs and single windows differ by country
Our answer: one connector per country, outside the core · start with one pilot port
Likelihood: 60 % (our estimate) · Response: reduce
Parallel initiatives split the effort
Our answer: talk early and propose one shared project
Likelihood: 40 % (our estimate) · Response: share
The community does not contribute
Our answer: DMS stays maintainer · value comes from configuration and operation, not contributions
Likelihood: 50 % (our estimate) · Response: accept
A flaw published before its fix
Our answer: SECURITY.md · coordinated disclosure · fix within 72 h targeted
Likelihood: 20 % (our estimate) · Response: reduce
Confusion between the open core and the models
Our answer: written boundary · two patents filed
Likelihood: 25 % (our estimate) · Response: avoid
The likelihood is our own estimate, a judgement rather than a measure. Responses: reduce · share · accept · avoid.
They work with DMS
🇨🇦 A container terminal in Canada · 🇺🇸 A container terminal in the United States
“One AI platform for the whole port city: setup offered, open code, and a subscription from day one.”
Olivier Raveau · Co-Founder & CTO, DMSLOG.Ai · About us
Open code around, our AI at the core. The models and business rules behind this page are ours, protected by our patents.
Tell us about your operations
A few words and we organise a call (Zoom, Teams, Meet).
- A first call. Your port, its community, the systems already in place and what the authority wants to change first.
- The bricks that already run. Appointments and the gate, shown as they work today; the bricks still in development are named as such.
- A first pilot port. Its scope, its connectors and its governance are set with the authority; no date is promised before that.
The open-source PCS
What the port community system does, brick by brick, and how it is built. Open-source PCS
Open source at DMS
Why we open our code, what is open and how to contribute. Open source
Other actors: Terminals · Shipping lines · Truckers · Forwarders · Shippers · Depots
