← URL Shortener

Why this stack

Every choice behind the URL Shortener serves one operating model: software you run yourself, with full control over where it lives and how it behaves. Here is the reasoning behind the runtime, the admin UI, the persistence option, the licence and the open-source base.

Java

A stable runtime platform for server-side operation.

The URL Shortener is built on Java. This fits the product’s self-hosted operating model because Java is widely understood in enterprise environments and can be deployed predictably across servers, containers, and controlled runtime environments.

For operators, Java keeps the runtime model explicit. The application can be started, configured, monitored, and integrated into existing operational practices without requiring a vendor-hosted platform.

For development teams, Java also supports maintainability. Tooling for builds, tests, packaging, profiling, and observability is mature and widely available.

Reference: Eclipse Temurin.

Vaadin

A browser-based operator interface built with server-side Java.

The URL Shortener uses Vaadin for the administration interface. The goal is a practical browser-based UI for managing links without requiring a separate JavaScript application stack.

Vaadin fits the project because it lets the operator UI stay close to the Java backend. This keeps the architecture compact and reduces the number of moving parts that must be built, deployed, monitored, and secured. The UI is intended for administrative and operational workflows: reviewing URL mappings, creating links, inspecting statistics, and working with the system in a browser.

Reference: Vaadin.

EclipseStore

Embedded, durable persistence for self-hosted deployments.

The URL Shortener uses EclipseStore as a persistence option for durable deployments. This keeps storage embedded in the Java application model and avoids making an external database service mandatory for the base operating scenario.

For a self-hosted URL management system, this can reduce infrastructure complexity. Teams can start with a compact deployment and still persist URL mappings and related data beyond process restarts. The storage choice should always be evaluated against the deployment’s operational requirements, including backup strategy, restore testing, disk placement, monitoring, and data retention policy.

Reference: EclipseStore.

EUPL 1.2

A European open-source licence for the open part of the project.

The open-source part of the URL Shortener is licensed under the European Union Public Licence 1.2. This aligns the project with a European open-source licence designed for software distribution in a European legal context.

For users and organizations, the licence is part of the trust model. It defines how the open-source part can be used, shared, and modified, and it makes the legal basis of the base version explicit instead of leaving the source availability unclear. Licensing should always be reviewed in the context of the organization’s own legal and compliance requirements; the project website can describe the chosen licence, but it does not replace legal review.

Reference: European Union Public Licence 1.2.

On-premises

Operation on infrastructure the customer controls — no mandatory cloud.

The URL Shortener is currently designed as an on-premises-only solution. The hosting location is not dictated by the vendor, and the system is not positioned as a mandatory SaaS or vendor-cloud service. Organizations decide where it runs: in their own data center, on a dedicated server, inside an internal platform, or with a trusted hosting provider of their choice. This is a deliberate operating model for teams that need clear control over infrastructure, network boundaries, data location, and compliance requirements.

Hosting sovereignty

Self-hosted operation gives teams direct control over the environment around the application — deployment pipelines, backup policies, monitoring, logging, access control, firewall rules, update windows, and incident procedures. For regulated or security-sensitive environments this matters, because URL management can be part of customer communication, internal routing, support processes, and operational documentation. The organization can place the system where its own requirements demand it.

What this does not imply

On-premises only does not mean a forced vendor cloud, and it does not imply a multi-tenant SaaS offering. The current positioning is self-hosted operation with full hosting choice on the customer side.

Open source

A transparent, inspectable core — not a black box inside your infrastructure.

The URL Shortener uses an open-source foundation for the base version. This matters for teams that do not want a URL management component to be a black box inside their infrastructure.

The open-source base gives technical teams a way to inspect the implementation, review the behavior of link creation and redirects, and understand how data is stored and processed. It also makes integration decisions easier, because the core behavior can be checked directly instead of relying only on product claims. For operators, open source reduces dependency risk: the system can be evaluated, tested, extended, and operated independently. Commercial or enterprise additions can still exist — see the editions — but the base functionality remains transparent.

Why it matters

Short links often sit in front of important internal tools, public campaigns, documentation, onboarding flows, and service entry points. If this layer fails or behaves unexpectedly, users notice immediately. An open-source base makes the technical contract visible.

Reference: URL Shortener Git repository.