DEV Community: XB Software

How We Automated a Production-Grade Traccar Deployment

Sergey Laptick — Mon, 20 Jul 2026 14:28:48 +0000

GPS tracking systems have become essential infrastructure for fleet management, logistics, delivery services, and field operations. Companies that manage vehicles, assets, or mobile workers need reliable visibility into where things are and where they have been.

Traccar is a mature open-source platform that handles such functionality well. The challenge is how to get it running in a production environment with monitoring, security, and the ability to customize it without spending weeks on setup.

We built an automated deployment script to solve this. We use it to deploy production-ready Traccar environments, then customize them according to our clients’ needs. This article explains how it works and what we deliver.

What Available Traccar Deployment Options Lack

Traccar is a system for tracking anything that moves: couriers, drivers, fleets, assets, etc. It includes a server, a frontend interface, and mobile applications that can function as GPS trackers themselves. The open-source version is available on GitHub, and anyone can download and try it. However, launching it and running it in production for years are two different things.

Most companies that need GPS tracking software do not want to spend time figuring out which database works best with Traccar, how to set up production environment monitoring so they know when something breaks, or how to configure a firewall to prevent data leaks. They want a system that works, stays running, and alerts them before it breaks down.

The default deployment options available today have gaps:

AWS Marketplace offers a basic Traccar instance at about $0.03 per hour. You get the software running, but the monitoring is whatever AWS provides by default. Limited styling, no tailored alerts, no ability to change how the system behaves;
Traccar's own hosted server for 50 devices costs around $49.95 per month in the US. It includes some branding options (logo, name and colors) with no UX or functional changes available. The server runs in Traccar's environment, not on the client's infrastructure. All data lives on Traccar's servers. For companies with a preference to keep their operational data on their own hardware, this is a non-starter;
Deploying Traccar yourself on your infrastructure from the open-source repository means your company owns and manages the entire stack. This option includes figuring out deployment, database configuration, reverse proxy setup, monitoring, alerting, and security. It is doable, but it takes time and expertise that most operations teams do not have to spare.

Here is how the available options compare and where we bring our expertise to the table:

What We Built: Automated Production Environment Deployment

When a client came to us needing a production-ready Traccar deployment without the usual headaches, we delivered it quickly and reliably. Here is what we built and how it works.

Instead of treating Traccar as a standalone application to be installed manually, XB Software built an automated deployment script that creates a complete production environment around it. The script runs on a Linux machine and handles everything needed to get Traccar running in a production-ready state.

Here is what the deployment includes:

Traccar backend and frontend;
PostgreSQL database;
Prometheus for metrics collection;
Alertmanager for sending notifications when things go wrong;
Nginx as a reverse proxy for monitoring interfaces;
Node exporter for Linux machine metrics;
PostgreSQL exporter for database metrics;
Firewall configuration using UFW/iptables to expose only necessary ports.

The script checks environment variables, installs Docker and Docker Compose, and generates configuration files from templates. It then sets up the firewall, clones the frontend repository (either standard Traccar frontend or a custom one), builds the stack, and starts everything. The logic strictly separates application, production environment monitoring, and data storage layers. When we update the Traccar interface or Alertmanager settings, the script performs smart, targeted restarts and rebuilds only the affected containers while leaving others untouched. This protects data from corruption, preserves active GPS tracker sessions, and maintains database uptime.

The deployment process with the script is fully idempotent. It never damages the system or creates duplicate resources. All original configuration templates remain on the server.

If a client needs to change monitoring passwords, update email alert settings, or modify any other configuration, there is no need for developers to edit complex files manually. They can update the corresponding variable in the centralized .env file and rerun the script. The infrastructure applies the changes without risking production stability.

For production-level reliability, we separated deployment logic from service management. Systemd handles stack availability, ensuring all containers restart automatically after a server reboot, while build and update tasks remain isolated within the deployment script.

System Architecture: Simple, Flexible, and Production-Capable

All the components listed above work together in a simple but production-capable architecture. Everything runs in Docker containers on a single server. For small to medium deployments this is more than sufficient. If tracking volume grows, the client can simply move the deployment to a more powerful server.

The Traccar backend and frontend are packaged in a single container. This is how Traccar's official Docker image works, and it keeps deployment straightforward. The frontend is written in React, and the backend runs on a custom Java server. The mobile applications (Traccar Client for drivers and Traccar Manager for fleet supervisors) are available from the official app stores.

For the database, we went with PostgreSQL. Traccar supports multiple databases, but PostgreSQL handles geospatial queries better than MySQL and manages high loads more effectively. For most fleets, the difference between databases is not dramatic, but PostgreSQL gives more headroom if tracking volume grows.

Prometheus and Alertmanager run in their own container. Prometheus scrapes data from two exporters. The Node exporter exposes such Linux machine metrics as CPU, memory, disk, network (these are the basic ones that can be extended if needed). The PostgreSQL exporter exposes database metrics. Together, they provide visibility into the health of the entire stack.

Nginx sits in front of everything. It routes traffic to Traccar, Prometheus, and Alertmanager. We added basic authentication to the monitoring interfaces so that metrics are not publicly accessible.

Why Traccar Integration Matters for Fleet Operations

Companies don’t buy tracking software and logistics solutions because they enjoy looking at maps. They buy them because they need to know where their vehicles are, how long drivers spend on routes, whether deliveries are on time, and whether assets are being used efficiently.

When the tracking system goes down, operations suffer. Dispatchers cannot assign jobs. Customers cannot get delivery updates. Managers cannot verify that routes were followed. The business loses visibility, and visibility is the whole point.

Our deployment approach addresses this directly.

Monitoring and Alerting: Knowing Before It Breaks

We built a deployment that not only works today but also tells you when it might stop working tomorrow. More vehicles get added. More trips get tracked. The database grows. Memory usage creeps up. CPU spikes during peak hours. Without monitoring, the first sign of trouble is often the system going down.

Our observability stack provides early warning. The alerts we configured track:

Host health: CPU, memory, disk usage, network activity;
Database health: PostgreSQL connections, query performance, storage;
Service availability: whether Traccar and its components are responding.

When metrics cross predefined thresholds, Alertmanager sends notifications. The client can see exactly what is happening on dashboards and plan upgrades before the system fails.

Security: Basic But Solid

Security follows the same principle as the rest of the stack: simple and effective. The script configures iptables (a traditional utility used to configure and manage IP packet filtering and NAT rules in the Linux kernel) to block all ports except those needed for the application to function.

This is essentially the same approach major cloud providers use with their security groups, just without the fancy UI. All internal traffic (database queries, exporter metrics collection) is fully isolated within Docker's private virtual networks and physically hidden from the outside world.

Customization: Frontend and Backend Modifications

A production environment also has to reflect the client's needs. One of the reasons companies choose Traccar is that they can customize it. In our experience, clients typically prioritize UX improvements. So we built flexibility into the deployment script accordingly. The repositories it uses are defined in environment variables. The frontend repo variable can point to the standard Traccar frontend on GitHub, a private repository with custom styles, or even a local directory.

This means we can:

Apply branding: replace the Traccar logo with the client's logo, adjust color palettes;
Modify UI elements: add, remove, or rearrange features in the frontend;
Update the frontend: pull new versions from the repository without changing the deployment script.

Most clients do not ask for backend changes. But for those who do need backend modifications (custom business logic, integrations with existing systems, specialized tracking features) we can handle those as well.

Support: Ongoing Maintenance, Adjustments, and Troubleshooting

Deploying the system is only the first step. When something drifts out of spec (memory spikes, database connection bloat, or unusual latency) we can diagnose it, and adjust the server or Traccar configuration before it becomes a problem.

Future Enhancements for Traccar Production Deployments

The deployment script is a foundation. As we work with more clients, we will refine the monitoring rules, expand the customization options, and improve the deployment process.

One area we are exploring is using AI-assisted development to accelerate frontend customization. Instead of manually modifying React components for each client, we could generate custom interfaces based on client requirements.

This is still in the exploration phase, but the potential is significant.

We are also considering how to handle larger deployments. Docker Swarm or Kubernetes would provide better scaling for fleet management software that works with hundreds or thousands of vehicles. The current script is a starting point, and we can build more complex architectures as client needs grow.

Conclusions

Traccar is a powerful GPS tracking system. But power without reliability is useless, and reliability without visibility is dangerous. Our automated deployment creates a production environment that combines Traccar's capabilities with the monitoring, security, and customization that businesses actually need.

Senior Developers Don’t Write More Code. They Prevent Disasters

Sergey Laptick — Thu, 09 Jul 2026 13:10:47 +0000

Imagine this. A team celebrates a massive release with dozens of features, thousands of commits, and months of late nights. Then, six months later, that same system is a maintenance nightmare. Bugs crop up everywhere. Onboarding new engineers takes weeks. Every small change breaks something else.

The problem is that many companies still measure senior engineers the same way they measure juniors: by output (more features delivered, more code in the repository, etc.). But that misses the real layer of seniority and results in production systems that fail from decisions that were never challenged.

Hidden Work of Senior Engineers

A senior developer’s day rarely looks like a productivity dashboard. They’re not constantly pushing commits or closing tickets. Instead, they’re doing things that look like they’re doing nothing:

Sitting in architecture discussions;
Mapping out failure modes;
Pushing back on vague requirements;
Asking “why” five times before anyone writes a spec.

None of this “ships.” But everything becomes safer because of it.

What actually separates a mid-level from a senior engineer in 2026 isn’t syntax mastery or knowing the latest build tool. It’s strategic thinking, technical influence, and the ability to balance trade-offs between speed, scalability, and maintainability. You can teach someone React in a week. Teaching them to see around corners takes years.

This invisible work is why senior engineers prevent problems that junior engineers cannot yet see:

Scaling bottlenecks before they exist;
Data consistency issues that only appear under load;
Dependency risks in third-party integrations;
Over-engineering disguised as “future-proofing”;
Under-engineering disguised as “MVP speed”.

A production outage is rarely a surprise. It’s a delayed decision that a senior engineer might have spotted six months earlier if anyone had listened.

The Paradox of Deleting Code or Why More Code Isn't Always Better

Here’s a counterintuitive truth that keeps coming up in engineering circles: your value as a developer becomes inversely proportional to the amount of code you write. Here’s how this so-called Deletion Paradox works. Junior engineers are busy adding features while senior engineers are quietly removing thousands of lines that never should have existed.

Why does that matter? Because every line of code is a future maintenance liability. It adds to the cognitive load, increases the surface area for bugs, and creates hidden coupling that will snap under pressure.

In mature systems, more code rarely means more value. It often means more operational complexity, more maintenance overhead, and more places where things can go wrong. The best way to improve a system is often to remove code, because you understand what happens after it ships.

Outcome Vs. Output: The Real Measuring Stick

This is where the shift from output to outcomes becomes concrete:

Output is what your team produces: a shipped feature, a release, a line of code. It’s easy to count, easy to celebrate, and easy to fake as progress;
Outcome is the measurable change in user behavior that creates business value: higher activation, better retention, more expansion revenue.

There’s this concept of “Feature Factories”, describing a situation where teams that celebrate activity and features delivered instead of business value and changed system behavior. The issue is that building a feature without an expected outcome is just a guess shipped at full cost.

Senior developers look at the backlog through the lens of hypotheses rather than blind commitments. They ask: “What are we trying to learn?” “What will change if this works?” “What’s the metric that moves if we get this right?”

This is why their most valuable contribution is often saying “don’t build this yet.” Not because they’re lazy or risk-averse, but because they can see that a feature will create long-term maintenance cost, or that an abstraction will break under real usage patterns, or that a shortcut will become technical debt faster than anyone expects.

At XB Software, we’ve seen this play out repeatedly in legacy app modernization projects. Sometimes the most valuable thing you can do is to know which parts of an old system to preserve and which to retire.

A UI redesign that strips familiar workflows can break user habits that took years to build. A senior engineer’s job is to see that coming and push back before anyone writes a line of code. That’s why we emphasize careful planning. The absence of a bad redesign often delivers more value than a dozen new screens.

What Changes When AI Generates Half Your Code

The Sonar 2026 State of Code Developer Survey found that 42% of production code is now AI-generated or assisted. 72% of developers who’ve tried AI coding tools now use them every day. That changes what “coding” means.

Anyone can generate massive amounts of code now. However, the hard part is knowing what not to generate, what to delete, and what to constrain.

As the VibeCoder Engineering Blog points out, a senior developer’s value in the AI era is building the guardrails. They write .cursorrules or CLAUDE.md files that encode project conventions, architecture patterns, and forbidden anti-patterns. The AI then generates code that follows their standards instead of generic best practices.

This is a form of systemic decision-making that happens before AI-generated code exists. AI cannot reliably make engineering trade-offs under business constraints. It doesn’t know when to choose simplicity over software scalability, or when to exchange speed for correctness. Those are still human judgments, and they’re exactly what senior engineers get paid for.

So while AI makes code cheaper, it makes engineering decision-making more valuable. The bottleneck here is editing, deleting, and deciding what not to build. The senior engineer’s job has shifted from writing code to writing rules that constrain the machines.

So What Does Seniority Actually Look Like?

Junior engineers optimize for “correct implementation.” They want to build the thing right. Senior engineers optimize for “sustainable system behavior.” They want to build the right thing, and sometimes that means not building anything at all.

The most important contribution a senior engineer makes is often invisible: shaping the system before it becomes expensive to fix. That’s the work that doesn’t show up in commit logs. But it’s the work that separates a stable product from a sinking one.

Senior developers don’t “do more.” They make sure the system doesn’t accumulate problems faster than the team can understand them. And in production, that is what defines success.

AI Can Write Code, But It Can't Own Production Systems

Sergey Laptick — Thu, 02 Jul 2026 13:36:27 +0000

AI is getting scary good at writing code. Drop a prompt into Lovable or Claude Code, and minutes later you have a working prototype with a modern tech stack. It feels like we solved all big problems in AI-assisted software development.

Then production happens. And production does not care how clean your code looks. It cares whether it survives reality. Can it handle traffic spikes or recover when a dependency fails at 2 AM? Can a person who inherits it six months from now actually understand what it does?

The uncomfortable truth is AI can generate code at scale, but it cannot own what happens after you deploy it.

The Illusion: "Perfect" Code from AI

What AI actually produces is impressive. Clean structure. Readable functions. Fast prototypes. Even decent architecture suggestions if you prompt it right. From the outside, it looks like senior-level output.

But here is the thing. AI does not understand business risk. It does not know what happens when your database connection pool runs out under load. It cannot tell you which of two equally valid solutions will survive a 10x traffic spike. It generates what looks right based on what it has seen before, not what is right for your specific system with its specific constraints.

Andy Anderson, a researcher at IBM, spent four months building a Kubernetes dashboard from scratch using Claude Code. No team. Just him and the AI. The first two weeks were exhilarating. Code poured out at a pace he had never experienced. Features that would normally take days appeared in hours. It felt like having a tireless junior developer who typed at the speed of thought.

Then the limitations hit. All at once: broken builds, wrong architectural patterns, scope creep, the AI trying to modify files Andy did not ask it to touch, etc. The problems were cascading: fix one thing, three others break. The researcher ended up spending more time reviewing and reverting than he would have spent writing the code himself.

We saw the same pattern with a scheduling app we built recently. Lovable generated a working prototype in hours with React frontend, Node.js backend, and PostgreSQL database. The calendar looked fine in the demo. But when we tested it, the AI-generated scheduler could not handle recurring events or drag-and-drop reliably. It was a concept car made of clay. So we swapped that component for DHTMLX Scheduler, a production-grade library, and rebuilt the backend for real-world scale. The prototype was useful, but the production system needed actual engineering.

This pattern shows up everywhere. The tools are great at generating code but terrible at understanding what the code is for.

Where Things Break: Production Reality

In production, systems behave differently. Traffic is unpredictable. Dependencies fail. Data grows. Users do things you never expected. Integrations become fragile. And suddenly, that “perfect” AI-generated code becomes just one layer in a very messy environment. The problem is not the code but everything around it

A large-scale study analyzing 302,600 verified AI-authored commits across 6,299 GitHub repositories found something sobering. AI-generated code introduces real issues, such as code smells, correctness problems, or security vulnerabilities, and 22.7% of those issues survive long-term, silently accumulating as technical debt in production codebases. More than 15% of commits from every AI coding assistant introduce at least one issue. Code that looks fine in a PR can quietly rot in production for years.

Stéphane Maes, who writes about software engineering, calls this the “Great Toil Shift.” The time you save generating code gets entirely consumed by the downstream work. This includes architectural review, security auditing, code understanding, documentation, and ongoing maintenance. The efficiency gains are not what they seem.

This is a common thing for teams that go all in on AI-generated code. The prototypes ship fast. Everyone is excited. Then the first production incident hits. The AI-generated code does something unexpected under load. Nobody fully understands the system because nobody wrote it. The team spends days debugging something that would have taken hours if they had built it themselves.

The Missing Piece: Engineering Judgment

Here is where the conversation needs to shift. What AI does is options generation. It gives you suggestions, often good ones. But someone still has to decide which suggestion to take. Someone still has to understand the trade-offs.

And they are the hard part:

Architecture trade-offs: Do we use a message queue or direct calls?
Failure handling: What happens when this service goes down?
Performance constraints: How many requests per second can this handle?
Security decisions: Is this endpoint properly authenticated?
Long-term maintainability: Will someone understand this in two years?

This is where experience matters more than output. Two solutions can both "work" in AI terms. But only one survives production load.

Andy Anderson's central finding from his experience report is worth quoting directly: "The intelligence of an AI-driven development system resides not in the AI model itself, but in the infrastructure of instructions, tests, metrics, and feedback loops that surround it."

In other words, AI is just a tool. The real system is everything you build around it. The tests. The review process. The deployment pipeline. The monitoring. The on-call rotation. The institutional knowledge about why things are the way they are.

In production environments, organizations fundamentally need what they call a "throat to choke," a human engineer who holds ultimate accountability, who can assess blame, who possesses the systemic intuition to troubleshoot complex, real-world failures. A machine cannot sign off on a Service Level Agreement (SLA). It cannot face a compliance audit. It cannot absorb liability for downtime.

This is not a philosophical point. Researchers who analyzed the terms of service for nine AI coding assistants found a consistent pattern: while users own the generated output, full liability, responsibility for correctness, and downstream production risk rests on the human user. The providers explicitly disclaim warranties and allocate responsibility to the developer.

If your AI-generated code causes a production outage, the AI company is not getting the pager duty alert. You are.

What This Means for How We Build Software

None of this means the tools are useless. They are incredibly useful. They can generate boilerplate, write tests, refactor code, and help you explore solutions faster than ever before. But the tools do not replace judgment. They do not eliminate the need for testing. They do not make architecture decisions for you. And they definitely do not own the systems they help you build.

The real skill in modern AI-assisted development is learning how to integrate generated code into a system that you fully understand, can debug, and evolve over time. It is knowing when to accept a suggestion and when to rewrite it.

Some teams are figuring this out. They use AI for rapid prototyping, like the Lovable-generated scheduler that we built, which validated the concept before replacing the AI-generated components with a production-ready solution. The prototype was useful for testing and validation. But the production system required real engineering: understanding the domain, handling edge cases, and ensuring the component could actually survive real-world use.

AI changes how fast we build software. But it has not changed what it means to be responsible for it. And in production, responsibility is still the hardest part.