Linux-Services with Delphi in production

Background services are the quiet productivity lever in many enterprise applications: data imports, exports, file and EDI processing, synchronization with ERP/DMS/CRM, scheduled workflows, notifications, or providing technical interfaces. In practice, however, success is not determined by the pure business function but by the question: can the service be operated, updated, monitored and restored in a controlled way in case of failure?

This is precisely where a sober look at Linux-services with Delphi pays off. Delphi is already a core part of the business logic in many organizations. When that logic can sensibly be reused server-side, a consistent overall architecture emerges: business rules are not implemented twice, interfaces remain stable, and teams work with established tooling. At the same time, Linux brings proven building blocks for operations, automation and security to the server world.

The crucial point: an Linux service is not a “small helper program” you run on the side. It is a product component with operational responsibility. This article shows concretely how Delphi-based Linux services can be set up robustly in production: from process and state model via systemd integration, logging, deployment and updates to monitoring, data access, security and typical failure modes. The goal is a setup that works in day-to-day operations—even at 3 a.m.

When Delphi services under Linux make sense

An Delphi-Linux service is appropriate whenever one or more of the following patterns apply:

• Existing Delphi business logic should be used server-side (e.g. validations, calculations, rule sets, import/export parsers).
• Background processing is an integral part of the application (e.g. PDF/reporting pipelines, job queues, batch processing).
• Integration load is increasing: many systems, many interfaces, many formats; reliable retryability (idempotence) becomes important.
• Modernization without a full rewrite: parts of the logic are extracted into services while the desktop client is gradually slimmed down.
• REST-servers & services should be considered together: the same code standards, the same logging/monitoring, the same rollout processes.

Less suitable is an Delphi service under Linux when a team has no Delphi expertise at all and a standardized platform (e.g. an existing Java/.NET ecosystem) is strictly mandated. In that case the issue is not Delphi itself but the organizational embedding. In many companies, however, Delphi is an existing asset that can be stably reused in the service layer—provided architecture and operations are planned cleanly.

Architectural fundamentals: process model, states, responsibilities

A productive service rarely fails because of the “main function.” More often it fails due to unclear states: What happens on a network outage? How does the service behave during a database failover? Is a job processed twice? Is behavior on SIGTERM defined? That is why every service needs a clear process and state model.

Service types: Always-on vs. Worker vs. Job-Runner

In the B2B context three basic types have become established:

• Always-on daemon: a continuously running process, e.g. listener, queue consumer, event dispatcher, websocket/push component.
• Worker pool: multiple instances processing jobs from a queue in parallel. Scaling is achieved by increasing the number of processes.
• Job-runner (timer): starts periodically, performs tasks and exits. Under Linux this is often better implemented with systemd timers/cron than with an internal scheduler thread.

Delphi can implement all three patterns. For operations it is crucial that the pattern is chosen deliberately. An “always-on” process that only does work every 15 minutes adds unnecessary complexity (memory leaks show up later, idle states are not handled cleanly). Conversely, a pure job-runner can be unsuitable when low latency is required.

Idempotence and restartability: the core of operational robustness

Productive operation means: services are restarted, deployments run, networks are temporarily unstable, databases have maintenance windows, and jobs are delivered multiple times. Therefore idempotence (running multiple times without side effects) for imports, exports and integrations is a guiding principle.

In practice that means:

• Each job has a unique job ID and a status (queued, running, succeeded, failed, dead-letter).
• Side effects (e.g. “invoice sent”) are recorded with a dedicated proof, not implicitly derived from logs.
• Retry strategies are controlled: backoff, maximum attempts, clear abort criteria, dead-letter queue.

When idempotence is applied consistently, a restart is not a crisis but a normal event.

systemd as the operational foundation: start, stop, restart, limits

Under Linux systemd is the central tool on most distributions to operate services cleanly. For Delphi services systemd is not “just” a start script but part of the stability architecture. A well-defined unit file is often the difference between “runs somehow” and “can be professionally operated”.

Important parameters in the unit file

For typical Delphi daemons the following aspects are relevant:

• Restart policy: e.g. Restart=on-failure or always, combined with RestartSec to avoid crash loops.
• TimeoutStopSec and KillSignal: enable orderly shutdown (flush queues, cleanly close DB transactions).
• User/Group: services should rarely run as root; principle of least privilege.
• WorkingDirectory and Environment: reproducible paths and environments instead of implicit assumptions.
• LimitNOFILE and resource limits: important with many concurrent connections/files.
• Logging integration: StandardOutput/StandardError to journald, plus possible forwarding to central log systems.

Restart policies must be chosen deliberately. A process that exits immediately due to a configuration error should not enter an endless restart loop and flood the system. In such cases exit codes and a “fail fast” with a clear error message are sensible.

Graceful shutdown in Delphi: SIGTERM is not a detail

In Linux operation a service is typically stopped via SIGTERM. An Delphi service should treat this as a normal state: no abrupt aborts but orderly termination.

In practice this includes:

• Set a stop flag, accept no new jobs.
• Let running jobs finish or abort them in a controlled way (depending on semantics).
• Commit/rollback transactions cleanly, close connections.
• Persist important status information (e.g. “Job X aborted, retry possible”).

A service that “dies hard” on SIGTERM produces inconsistencies and makes maintenance harder.

Configuration: reproducible, versionable, secure

Many production issues are ultimately configuration problems: wrong DB host, wrong credentials, missing paths, divergent timeout values between environments. Configuration is therefore not just “an INI file” but a concept.

Configuration sources and priorities

A multi-layered model has proven effective:

• Default configuration in code (secure baseline, sensible timeouts).
• File-based configuration (e.g. INI/JSON/YAML) that can be deployed versioned.
• Environment variables for secrets and environment specifics (container/CI friendly, no secrets in the repo).

Important is a clear priority (e.g. env overrides file overrides default) and a startup check that validates configuration: required fields, reachability, file permissions, minimal value ranges.

Secrets: not in plaintext, not in logs

In B2B environments database passwords, API tokens, certificates and private keys are among the most important operational assets. Minimal standards:

• Do not keep secrets in Git and avoid plaintext secrets in deployed configuration files when feasible.
• Read permissions for config/secrets only for the service user.
• Log output must consistently mask secrets (also in exceptions).

Whether a vault system is used or classic deployments with restrictive rights: the decisive factor is that secret handling is systematic.

Logging: from “error text” to operational diagnosability

A productive Linux service is only as good as its diagnosability. “There was an error” does not help. In an incident, operations and development must be able to reconstruct: what was the input? Which version was running? At which step did the failure occur? Was it a transient error or a data problem?

Structured logging and correlation IDs

For services with interfaces (REST, MQ, file imports) two things are central:

• Structured logging (key-value, JSON-like): service, version, env, job_id, customer_id (if permitted), duration_ms, result.
• Correlation ID: an ID propagated across components (e.g. from the REST request into the worker job).

With these you can not only find production errors but also narrow them down: does it affect all customers? Only one data source? Only one version? Only one instance?

Log levels, noise and operational signals

A common anti-pattern is too many logs without signal: megabytes of “Processing…” on every poll. Instead:

• INFO: relevant state changes (start, stop, config loaded, job started/completed).
• WARNING: expected deviations (retry, transient network error, timeouts).
• ERROR: unexpected conditions requiring manual action.
• DEBUG: selectively activatable, time-limited.

Especially in systemd/journald environments it is sensible to plan log rotation and retention. Without a retention concept logs are either kept too briefly (no diagnosis) or consume disk space (operational problem).

Monitoring and health: not just “running” — but “delivering”

A process can run and still be functionally dead (stuck in a deadlock, waiting on IO, or not processing jobs). Production readiness means: monitoring checks not only the process state but service health.

Health checks: liveness, readiness, business checks

For Delphi services three levels make sense:

• Liveness: process is alive (systemd status, watchdog, simple ping endpoint).
• Readiness: service is ready (DB connection possible, configuration valid, dependent systems reachable).
• Business check: is the service actually processing? e.g. “last successful job < 10 minutes” or “queue length < threshold”.

The business level is often the most important in B2B operations because it measures actual value delivery.

Metrics: runtimes, error rates, backlog

When services grow, logs alone are no longer enough. Metrics help to see trends:

• Throughput (jobs/min), average job duration, p95/p99 runtimes.
• Retry rate, error rate by error class (network, data, auth).
• Queue backlog, wait times, dead-letter counters.

Even without a complex observability stack, useful results can be achieved with simple exports (e.g. via an internal HTTP endpoint or log-based parsing). What matters is consistent definition of metrics and thresholds.

Data access and transactions: FireDAC, connection handling, pooling

Many Delphi services are database-centric. Under Linux access with Delphi is typically organized via BDE replacement with native bindings and native client libraries. For production readiness the decisive aspects are less the “right drivers” and more the connection and transaction model.

Connection lifecycle: short-lived vs. long-lived

For background jobs a proven practice is:

• Open a connection per job or job batch, work, close (robust in the face of network interruptions).
• For high-frequency jobs consider connection pooling, but only with a clean reset between jobs.

Long-lived connections can work but tend to fail into hard-to-diagnose states on network interruptions or DB failovers. Short-lived connections are often the more robust default — with appropriate timeouts and retries.

Transaction boundaries and locking behavior

Production issues often stem from transactions that are too large: long locks, blocked tables, “everything hangs.” Better:

• Align transactions to business units (e.g. “one import record” or “one document”).
• Persist intermediate results to enable restartability.
• Classify errors cleanly: data errors (do not retry), network errors (retry), side effect already occurred (handle idempotently).

With parallel workers, locking and deadlock behavior is a design factor — not just a DBA topic.

Deployment and updates: reproducible, rollbackable, low-risk

A service is never “finished”; it gets updated. Therefore deployment is not an afterthought but part of the solution. In production three properties count: reproducibility, rollback capability and minimal downtime.

Versioning and artifacts

Proven practices are:

• Each build carries a unique version (SemVer or build ID) and logs it on startup.
• Artifacts are immutable: the same version is not rebuilt and overwritten.
• Dependencies (e.g. native libraries) are part of the deployment or clearly documented.

This avoids the common production problem that “version X” actually differs slightly per server.

Update strategies: rolling, blue/green, stop/start

The appropriate strategy depends on the pattern:

• Stop/start: for job-runners or non-critical services; simple but with short downtime.
• Rolling update: restart multiple instances one after another; queue-based systems are well suited.
• Blue/green: two separate environments, switch via load balancer; higher effort, minimal risk.

Important: an update is only “safe” if the service expects a compatible database/schema version at startup or migrations are run in a controlled manner. Schema changes are their own rollout step with a plan (forward/backward compatible, or with a maintenance window).

Security and operational hardening: small measures, big effect

Linux services are often close to data, interfaces and credentials. Hardening is therefore not a luxury. A few standards already reduce risks significantly.

Least privilege and file permissions

• Dedicated service user without shell login, minimal group privileges.
• Configuration and secret files readable only by that user.
• Write permissions only where necessary (e.g. working directory, spool, temp).

Network boundaries and port management

If an Delphi service opens ports (e.g. as a REST-server), the following applies:

• Bind to internal interfaces if external reachability is not required.
• Firewall rules and segmented networks instead of “open in the LAN.”
• Plan TLS termination properly (reverse proxy, certificate rotation) depending on the environment.

Even internally, services should not assume that only well-behaved clients will call them. Authentication and authorization are part of the design.

Typical failure patterns in practice — and how to avoid them

In production recurring patterns are often what costs teams time. Some typical cases and countermeasures:

“The service is running but not processing anything”

• Cause: deadlock, blocking IO, silent reconnect problem.
• Countermeasure: timeouts everywhere; watchdog/business health check; worker architecture instead of single-thread; fail-fast on broken dependencies.

“After an update jobs are processed twice”

• Cause: missing idempotence, no dedicated job table, side effects not atomic.
• Countermeasure: job status in DB, unique constraints, outbox/inbox pattern, deduplicable events.

“Logs don’t help — only stack traces without context”

• Cause: unstructured logging, no correlation ID, no job context.
• Countermeasure: structured log fields, job ID, input source, duration, result, error class.

“The service collapses under load”

• Cause: uncontrolled concurrency, missing backpressure, too many DB connections, too large transactions.
• Countermeasure: worker limits, queue lengths, connection limits, small transactions, buffering and retries.

Interaction with REST servers and existing enterprise software

In many architectures there is not a single service but a package of REST server, background workers and clients. In Delphi projects it is often sensible to keep shared business logic in clear modules while transport- and operations-specific parts remain separate.

Separate layers cleanly (business and technical)

A pragmatic structure:

• Domain/business logic: rules, validation, calculations, use cases.
• Infrastructure: DB access, filesystem, HTTP clients, messaging.
• Adapters: REST endpoints, service loop, CLI runner, systemd-near start logic.

This separation is not academic. It enables the same business logic to be used in the REST server and in the worker while operational aspects (timeouts, retries, logging, health) can be implemented consistently.

Multiplatform consideration: Delphi as a unified codebase

If companies already use Delphi for Windows clients, an Linux service can be the next logical step: the same language, similar libraries, unified build pipelines. The benefit only arises if platform boundaries are respected deliberately (file paths, case sensitivity, locale/encoding, service user rights, deployment conventions). Multiplatform operation is always “detail work” — which is why it should be planned early.

Practical checklist: what a productive Delphi-Linux service needs at minimum

• systemd unit with sensible restart/timeout rules, dedicated service user, defined paths.
• Graceful shutdown (SIGTERM), no data inconsistencies on stop.
• Configuration model with validation, secrets secured, no secrets in logs.
• Structured logging with version, job ID, correlation ID, duration, error class.
• Health checks (at least readiness + business check) and defined metrics.
• Idempotent job processing, retry/backoff, dead-letter concept.
• Deployment with clear versioning, rollback strategy, planned schema migrations.
• Resource and load concept: concurrency, limits, timeouts, connection handling.

Conclusion: Delphi under Linux is not a special case — if operations are considered

Linux services with Delphi are a very solid option in production when treated as a full system component: with clear architecture, clean systemd integration, robust error and state model, traceable logging, monitoring and reproducible deployment. The technical implementation is rarely the risk; the risk lies in the “operational details” that are clarified too late.

Those who plan these details from the start get a maintainable service landscape that reuses business logic consistently, processes integrations stably and is reliably operable in day-to-day life — including updates, restarts and incidents.

If you would like to assess how your existing Delphi business logic can be transferred into Linux services, workers and REST servers (including operations and deployment concepts), we are happy to clarify the boundary conditions in a structured technical initial meeting: Contact.