Most terminal software coverage is written about products aimed at transhipment hubs, which leaves the operator of an
inland depot or a single berth terminal reading about capability they will never use. Octopi tos and iPortman belong
to a different tier built deliberately for that operator, and a recognition layer
connects to either one the same way. This article explains what the lighter tier does well, where its ceiling sits, and how to tell whether your
terminal belongs there.

Key Takeaways

• The lighter tier trades optimisation depth for being operable by a small team, which is the right trade when your
  binding constraint is people rather than software.
• Octopi is a cloud native product built for smaller and mid sized terminals. iPortman comes from the Indian market
  with port community and customs integration already handled.
• Time to value is the headline advantage. Implementations run in weeks, configuration is achievable in house, and
  subscription pricing avoids capitalising a licence you may regret.
• The ceiling is real. Test yard planning behaviour under congestion at twice your current volume before you sign,
  because that is where the tier reaches its limit first.

What the Lighter Tier Actually Optimises For

Enterprise platforms optimise for move efficiency at very large scale, because at four million containers a year a one
percent crane productivity gain funds a systems department. The lighter tier optimises for something different: the
total effort required to run the terminal, including the effort of running the software itself.

That reframing explains most of the design decisions. Configuration is simplified because the buyer has no consultant
on retainer. Implementation is short because the buyer cannot fund a year long project. Pricing is subscription
because the buyer would rather not capitalise a licence for a volume forecast that may not arrive.

It also explains what is missing. Deep stowage optimisation, multi berth crane sequencing and adaptive yard strategies
that respond to congestion in real time are either simplified or absent. For an operator with one berth and a stable
yard, none of those absences is felt.

The question is therefore not whether the lighter tier is less capable. It plainly is. The question is whether the
missing capability would have been used. A module nobody configures delivers exactly the same operational value as a
module that was never purchased, at a considerably higher price.

There is a second order benefit that rarely appears in comparisons. Simpler software gets used more completely.
Terminals on lighter platforms tend to have most of the product switched on, while terminals on enterprise platforms
frequently run a fraction of what they licensed.

That completeness matters operationally. A planner who trusts the system recommendation because it reflects how the
terminal actually works will follow it. A planner who overrides a sophisticated optimiser because it was configured
once in 2022 and never revisited is doing the planning manually.

Octopi and Where It Fits

Octopi is a cloud native terminal operating system built specifically for small and mid sized terminals, inland depots
and multipurpose facilities. Its design assumption is that the customer has no dedicated systems team, and every part
of the product reflects that from onboarding through to day to day administration.

The practical consequence is speed. Implementations are measured in weeks, configuration is done by terminal staff
rather than consultants, and the subscription model means the commitment is annual rather than capital. For an
operator who has watched a peer suffer through a long enterprise implementation, that alone is persuasive.

Being cloud native cuts both ways. It removes server management and upgrade work, which is a genuine saving for a
small team. It also means your operational system depends on connectivity, which needs thinking through at a terminal
where the link is not always reliable.

That connectivity question is worth separating from the recognition layer. Gate OCR should run
on premises
at the edge regardless of where the platform lives, so that trucks keep being processed when the link drops and
results are forwarded once it returns.

Octopi suits terminals under roughly half a million containers a year, operators expanding across several small sites
who want consistency without enterprise cost, and any terminal whose current system is a set of spreadsheets that has
quietly become critical infrastructure.

It suits less well where planning complexity is genuinely high, where regulatory integration is heavy and locally
specific, or where a parent group has standardised on a platform and consistency across sites outweighs local fit.

iPortman and the Regional Compliance Advantage

iPortman comes out of the Indian market and carries something imported products do not: integration with local port
community systems, customs interfaces and statutory reporting already built and maintained. For a terminal in India
that is not a feature, it is the removal of a work package.

The size of that work package is easy to underestimate. Customs interfaces change, port community system requirements
evolve, and a terminal running an imported platform either pays a local partner to keep pace or discovers a compliance
gap during an audit. Neither is a small ongoing cost.

Beyond compliance, regionally built platforms tend to reflect local operating practice. Document flows, gate
procedures and the way inland depots interact with ports in India are not the same as in northern Europe, and software
built around the local pattern needs less bending to fit.

The trade is ecosystem size. Fewer integrators know the product, fewer third party tools connect to it out of the box,
and there is less accumulated public knowledge to draw on when something breaks at two in the morning during peak
season.

That makes interface openness more important, not less. Ask in writing what interfaces exist, whether they are
documented, whether calling them requires vendor involvement and whether they carry a separate licence. A regional
platform with an open interface is an excellent choice.

It is also worth asking how the vendor handles a customer who wants an independent automation layer. A cooperative
answer suggests a partner. A defensive one suggests you will be negotiating access to your own operational data later,
which is a poor position to be in.

Testing the Ceiling Before You Sign

Every product in this tier has a volume band it was engineered for, and the failure mode is not a crash but a slow
degradation in planning quality as the yard congests. That degradation is invisible in a demonstration because
demonstrations use tidy data and empty stacks.

The test that works is to ask for a reference site at twice your current volume and speak to them directly. Not the
vendor case study, the operations manager. Ask what happens to slot allocation quality when the yard is at ninety
percent and three vessels are working simultaneously.

Ask about the reporting burden too. Smaller platforms sometimes handle daily operations well and struggle when a
shipping line customer wants a bespoke monthly report, at which point somebody starts exporting to spreadsheets and
the single record quietly fragments again.

Test the exception path in a trial. Create a container that arrives without a booking, one that arrives twice, and one
whose details do not match the manifest. How the product handles those says more about daily life with it than any
planned scenario in a scripted demonstration will.

Finally, size for three years rather than ten. If your growth plan genuinely takes you past the tier, plan the
platform change explicitly and keep your automation layer independent so the change costs one migration rather than
three.

That last point is the practical protection. A terminal whose gate recognition sits outside the platform can move
between tiers without touching cameras, accuracy baselines or gate process, which is what makes starting light a
reversible decision. See our note on
choosing an automation partner
for the questions that matter.

Conclusion

The lighter platform tier exists because most terminals in the world are not transhipment hubs. Octopi tos and
iPortman solve for total operating effort rather than for peak optimisation, which is the right objective when your
constraint is people. Choose on fit, test the ceiling with a reference site at twice your volume, and keep the
automation layer independent so the decision stays reversible.
Ask Docker Vision how gate
data would flow into either.

Frequently Asked Questions

What is Octopi tos designed for?

Octopi is a cloud native terminal operating system built for small and mid sized terminals, inland depots and
multipurpose facilities. It assumes the customer has no dedicated systems team, so configuration and administration
are deliberately kept within reach of operations staff.

How does iPortman differ from an imported platform?

iPortman ships with Indian port community, customs and statutory reporting integration already built and maintained.
An imported platform leaves that work with you or with a local partner, which is a recurring cost rather than a one
time project.

Is a lightweight platform less reliable than an enterprise one?

No. Reliability is not the difference. The difference is optimisation depth and configurability. Lighter products
handle fewer complex planning scenarios but are frequently used more completely, because a small team can actually
operate all of the product.

What volume is too large for the lighter tier?

There is no universal figure, but the tier is commonly engineered around terminals below roughly half a million
containers a year. Congested yard planning is where limits appear first, so test that specifically at twice your
current volume.

Does a cloud platform mean the gate stops when the link drops?

It should not. Keep recognition running at the edge on terminal hardware so trucks continue to be processed during an
outage and results forward once connectivity returns. That separation is a design decision worth insisting on early.

Can we start light and move to an enterprise platform later?

Yes, and it is a reasonable plan if growth genuinely demands it. Keeping the automation layer independent of the
platform is what makes the move cost one migration instead of simultaneously replacing cameras, gate process and
accuracy baselines.

What should we ask a reference site?

Ask the operations manager, not the sponsor, what happens to slot allocation when the yard is at ninety percent with
several vessels working. Then ask what they export to spreadsheets, because that reveals every gap the product left
open.

Do lighter platforms integrate with gate OCR?

Generally yes, through an interface or a message queue. Confirm the interface is documented, callable by your own team
and not separately licensed, because those three conditions decide how expensive every later automation project
becomes.

Is subscription pricing better than a perpetual licence?

For a smaller terminal it usually is, because it avoids capitalising against a volume forecast that may not arrive.
Model five years of total cost including internal time before deciding, as our
overview for modern terminals
recommends.