Most terminal operators have been told an automation project takes a quarter at minimum, and many have lived through
one that took three. That expectation comes from a hardware era that has largely ended. Automated terminals that use
standard cameras and containerised software
now reach a working go live in days, because almost nothing physical has to be built. This article explains what
actually changed, what a short deployment looks like hour by hour, and which parts of a rollout still take longer than
anyone would like.

Key Takeaways

• The long timeline in a classic automation project comes from civil works and specialist hardware, not from the
  recognition software itself.
• Docker Vision publishes a two day implementation figure for its gate OCR product, which is achievable because the
  software ships as a container onto hardware the terminal already owns.
• A fast go live is not a shortcut. It changes the risk profile, because you see live accuracy on your own traffic
  before you have committed to anything structural.
• Integration mapping, acceptance criteria and staff process changes still set the real end date, and those are
  terminal side tasks rather than vendor side ones.

Why Terminal Automation Projects Usually Take Quarters

The quarter long timeline is real, but it belongs to a specific architecture. A line scan camera installation needs a
gantry, a foundation, trenching for power and fibre, a lighting design and an electrical inspection. Every one of
those is a civil works item with its own lead time, and none of them can be compressed by writing better software.

Procurement adds its own months. Specialist imaging hardware is rarely held in stock, so an order placed in January
can arrive in April, and the crew has to work around a terminal that cannot stop handling boxes. Night and weekend
working stretches a two week job into six.

Then there is commissioning. A hardware rig has to be aligned, calibrated and tuned against real traffic, and the
tuning loop is slow because each adjustment needs another day of live moves to evaluate. Terminals that have been
through this remember the commissioning phase, not the software install, as the part that overran.

The result is a business case that has to survive a long gap between signature and benefit. Finance teams discount
heavily for that gap, which is one reason automated terminals stay a plan rather than a project at mid sized
operators. A shorter path to first value changes the arithmetic more than a lower price does.

It also changes who has to be convinced. A project that needs foundations needs the engineering department, the safety
committee, a contractor and often the port authority. Installing software onto an existing server needs the IT lead
and the operations manager, and nobody else.

None of this means hardware based systems are wrong. It means the timeline they carry is a property of the hardware,
and a terminal evaluating
which supplier to appoint
should ask what physically has to be built before assuming a quarter is inevitable.

What a Containerised Deployment Actually Changes

Docker Vision ships its recognition engine as a
Docker
container that runs on the terminal own hardware. The practical consequence is that installation becomes a software
operation. There is no rig to mount, no foundation to pour and no proprietary camera to wait for, because the system
reads from standard IP or CCTV cameras.

That single decision removes most of the calendar. A container carries its own runtime and dependencies, so the engine
behaves the same on a terminal server in Kochi as it does on a test machine, and the usual week of environment
troubleshooting simply does not happen. Deployment becomes repeatable rather than bespoke.

It also keeps the data inside the fence. Running
on premises
means image frames and recognition results never leave the terminal network, which matters for operators whose customs
authority or parent group restricts where operational data may be processed. The client has written about this at
length in its piece on
keeping operational data inside the fence.

Scaling follows the same logic. Adding a second lane or a second gate is another container instance against another
camera feed, not another civil works project. Terminals that start with one lane and expand across a year find the
second lane takes hours, because the pattern has already been proven on the first.

The camera question is the one operators probe hardest, and reasonably so. The honest answer is that commodity cameras
work when placement, focal length and lighting are right, and the client sets out those requirements openly rather
than treating them as a trade secret. Placement is a survey task, measured in hours, not a procurement task measured
in months.

What containerisation does not remove is the need for a competent host. The terminal has to supply a machine with
enough compute, a stable network path to the cameras and somebody with server access on the day. Those are small asks,
but a deployment stalls on them more often than on anything technical.

The Two Day Go Live Sequence, Step by Step

The published two day figure describes a specific sequence rather than a marketing round number, and it helps to see
it laid out. Day zero is a survey. Somebody walks the lane, checks camera positions and angles, confirms the network
route and records what the existing camera estate can see.

Day one is installation and first recognition. The container is deployed to the terminal server, camera streams are
connected, and the engine starts reading
ISO 6346 container
codes off live traffic. At this point the system is reading but not yet writing anywhere, which is deliberate.

Day two is calibration and handover. Recognition results are compared against what the gate clerk recorded, thresholds
are adjusted, edge cases are captured, and the output is pointed at wherever it needs to go. For most terminals that
means an API call into the operating system, which the client covers in its post on
reading a container in realtime.

The reason this compresses so well is that each step depends on the one before it rather than on an external supplier.
Nothing in the sequence waits for a delivery, a contractor or an inspection, so the critical path is simply how fast
the terminal can make decisions.

A useful discipline is to treat the first week after go live as observation rather than as success. Run the automated
read alongside the manual one, log every disagreement, and only retire the manual step when the disagreement rate has
been stable for several days across all shifts and weather conditions.

That parallel period is also where a terminal learns its own traffic. Every gate has its own mix of damaged plates,
repainted boxes, unusual approach angles and one operator who always stops two metres short. Those quirks are
invisible in a demonstration and obvious within a week of live running.

What Still Takes Longer Than Two Days

Recognition going live in two days does not mean the project finishes in two days, and automated terminals that
pretend otherwise set themselves up for disappointment. The parts that take longer sit on the terminal side of the
boundary, which is good news, because the operator controls them.

Data mapping is usually first. Your operating system expects specific fields in a specific format, and somebody has to
decide what happens when the OCR read disagrees with the booking, when a code is partially obscured, or when a box
arrives that no appointment predicted. Those are business rules, not software settings.

Acceptance testing is second. Writing a defensible accuracy target, agreeing how it will be measured and choosing the
sample that will be used takes longer than the install itself, and it should. The client has published a detailed
treatment of
TOS integration
that is worth reading before that conversation starts.

Third is people. A gate clerk whose job has been to key container numbers for eleven years needs a clear answer about
what happens next, and terminals that skip that conversation see quiet resistance that shows up as unexplained manual
overrides. Redeployment plans work better than reassurance.

Fourth is scope creep, which arrives disguised as enthusiasm. Once the gate is reading reliably, somebody asks about
damage capture, then rail, then the yard. Each is achievable, and each is a separate decision that deserves its own
case rather than being absorbed into a project that has already been signed off.

Handled deliberately, a realistic shape is recognition live in days, parallel running for two to four weeks, full
manual retirement inside a quarter and the next lane after that. That is still a different order of magnitude from the
traditional
terminal automation rollout, and the difference compounds every time you add a lane.

Conclusion

The quarter long automation project was never a law of physics. It was a consequence of building gantries and buying
specialist cameras, and terminals that no longer need either can reach a working read on live traffic inside two days.
What remains is the work only the operator can do, which is deciding what the data means, how accuracy will be judged
and what the gate team does next. If you want to know what that sequence would look like against your own lane layout,
talk to the Docker Vision team
about a site survey.

Frequently Asked Questions

How can automated terminals go live in two days when other projects take months?

The two day figure applies to software that reads from cameras the terminal already owns. No gantry, foundation or
specialist imaging hardware is involved, so the schedule is set by decisions rather than by procurement and civil
works lead times.

What does the terminal have to provide before installation starts?

A server with adequate compute, a stable network path to the gate cameras, administrator access on the day, and one
operations contact who can answer questions about lane layout and traffic patterns. Everything else arrives with the
deployment.

Do standard IP cameras really work as well as line scan cameras?

For gate lanes at normal approach speeds, yes, provided placement, focal length and lighting are right. Docker Vision
publishes recognition accuracy above 95 percent using commodity cameras, and the placement requirements are shared
openly rather than hidden.

What is the difference between recognition going live and the project finishing?

Recognition going live means codes are being read from live traffic. Project completion means the reads are trusted,
mapped into your operating system, covered by an accuracy agreement and the manual keying step has actually been
retired.

How long should parallel running last before manual keying stops?

Two to four weeks is typical. You want the automated read and the manual read compared across every shift, both
weather extremes and at least one peak period, so the disagreement rate reflects real operating conditions rather than
a quiet week.

Does a containerised deployment mean our data goes to the cloud?

No. The container runs on terminal hardware inside your own network, so image frames and recognition results stay on
site. That is the point of the architecture, and it is what makes the approach workable where data residency rules
apply.

What happens when the OCR read disagrees with the booking record?

That is a business rule your team defines rather than a software default. Common patterns are to flag for clerk
review, to trust the physical read, or to hold the move until the discrepancy is resolved by the
gate operations team.

Can we start with one lane and expand later?

Yes, and most terminals should. A second lane is another container instance against another camera feed rather than
another construction project, so expansion takes hours once the pattern has been proven on the first lane.

How does a fast deployment change the business case?

It shortens the gap between spending and benefit, which finance teams discount heavily. You also see real accuracy on
your own traffic before committing anything structural, which converts a forecast into evidence. See the
edge computing explainer
for the architecture behind it.