Skip to content
DE:LIVER In development
Product · Decent Edge

Publish content to the servers that serve it. Signed, versioned, reversible.

DE:LIVER moves content the way DE:PLOY runs services. Publish a new version of a site to its servers, deliver collected data to the machines that process it, and know that what arrived is exactly what was sent.

Signed content delivery and publishing for the sovereign edge.

Every organization moves content around: a new version of a website, a release artifact, a document set, a day of collected mail. Today that is FTP uploads, ad hoc scripts, and hope. DE:LIVER replaces them with one model: content is packaged into a signed, versioned release, and a delivery moves that release from where it is made to where it is used.

DE:PLOY installs and runs IT services. DE:LIVER is its sister for content: it moves, versions, processes, and verifies the content those services serve and consume.

The problem

Content still travels the old way: an FTP upload, an scp from a laptop, a script that only one person understands. A page goes up half-copied. Nobody can say which version is live. Rolling back means finding the old files and hoping. Moving data from a server to the machine that processes it is another pile of cron jobs and forced-command pulls, with no record of what arrived.

DE:LIVER replaces that with delivery you can account for: every release is a named, signed version, and every transfer has a receipt.

Who it is for

Teams that publish websites, release builds, or files to servers they run themselves, and teams that need new content from a server delivered to a processing machine.

How it works

A client for authors and CI creates a release; a server agent receives it, verifies it, and puts it live. No FTP, no shared passwords.

  1. STEP 1
    Author

    Build your content where you always do: a site generator, a CI job, a folder.

  2. STEP 2
    Publish

    The client packages a release: a manifest with content hashes, the version, the recipe that produced it, and a signature.

  3. STEP 3
    Deliver

    The agent on the target pulls the release over an authenticated channel, checks every hash and the signature, and stages it beside the live version.

  4. STEP 4
    Switch

    One atomic step makes the new version live. Visitors never see a half-copied site.

  5. STEP 5
    Keep or revert

    Earlier versions stay available. Roll back in one command, or revoke a version so it can never be delivered again.

Push publishing

Publish a new site version to the servers that host it, and take it back just as fast.

Atomic switch

A new version goes live all at once or not at all. Visitors never see a half-uploaded site.

Instant rollback

Every release is kept as a version. Return to the previous one in a single step.

Versions and revoke

Browse what was published when. Revoke a release so it can no longer be served or redelivered.

Automatic delivery to processing machines

Delivery also runs from servers to the machines that work on the content: collected mail to an analysis box, exports to a build machine.

Receipts

Each item is acknowledged when it is safely stored, so the sender knows what arrived.

No loss, no duplicates

A delivery can be retried safely, and an item that already arrived is not delivered twice.

Receipts and replay

Each delivery produces a signed receipt: what was sent, what arrived, when. Interrupted transfers resume.

Push-like, without open doors

The receiving machine does not need to expose a service to be reached.

Pluggable sources and targets

A release is the same signed object whatever carries it. Sources and targets are adapters.

Git and HTTP

Read from a repository or a web server; publish to either.

Local folders and object storage

Work with a directory on disk or an object store.

epher networks

Planned: use an epher network as an optional backbone for distribution.

Recipe-driven processing

Processing is declared, not scripted by hand, in the style of DE:PLOY recipes.

Build, render, convert, minify

Final builds, document and image conversion, and minification run as steps on the way.

Reproducible

The signed manifest records the recipe and its inputs, so a release can be rebuilt and compared.

Where you choose

Run steps on the client, on the server, or on a separate builder.

A client for authors and CI, an agent on the server

Two parts, one protocol.

Client

A command-line client for authors and CI pipelines creates, signs, and publishes releases.

Server agent

A small agent on each target verifies releases and manages versions and rollback.

Least privilege

The agent reads only from sources it is allowed to read and writes only into the targets it serves, over authenticated, encrypted channels.

Shared protocol

Both speak the same signed protocol, so a release is checked the same way wherever it lands.

Part of the Decent Edge suite

DE:LIVER moves content; these products make that safe and repeatable.

DE:LIVER DE:SIGN DE:PLOY DE:TECTOR DE:SAFE epher
DE:SIGN
Signs releases, so a target accepts only what an authorized signer published.
DE:PLOY
Shares the recipe engine, and deploys DE:LIVER's server agents by recipe.
DE:TECTOR
Admits the delivery channel, so a target accepts connections only from identities it recognizes.
DE:SAFE
Holds sensitive content and keys with zero-knowledge storage when a release must stay opaque to the storage layer.
epher
Planned: an optional backbone for distribution and anchoring.

Where it fits

Websites

Publish each new version of a site to its servers, switch atomically, and roll back instantly.

Release artifacts

Distribute signed binaries and packages with a version history.

Documents

Deliver rendered document sets to the places that serve or archive them.

Mail and data collection

Move collected mail and data to analysis machines with receipts.

Edge fleets

Keep content current across many small sites, each verifying what it receives.

Where it sits

  1. FTP and hand-written scripts

    Simple, but unversioned and unverified: no atomic switch, no rollback, and a shared password.

  2. Git-based or CI-only deployment

    Good for code, awkward for large content and for delivery to machines that only receive.

  3. DE:LIVER

    Signed, versioned releases with atomic switch, rollback, pluggable sources and targets, and recipe-driven processing, on your own servers.

Why it is different

  • Signed by default. A release is not a pile of files; it is a manifest anyone can verify.
  • Reversible by design. Rollback and revoke are part of the model, not a script you write after the incident.
  • Backend-neutral. Git, HTTP, folders or object storage (epher is planned): the release stays the same.
  • EU-built and self-hosted. Runs on your own servers, built by GINF Systems Kft. in Hungary, with no central service in the path.

DE:PLOY runs your services. DE:LIVER gets the content to them and to the people who use it, and can prove what it delivered.

Talk to us