FACET — Faculty of Exact Sciences and Technology

Design, Implementation and Deployment of an On-Premise Electronic Document Signing System for FACET

Fabricio Blasich

Final Degree Project · Computer Engineering
Faculty of Exact Sciences and Technology — UNT

Advisors: Mg. Carlos Albaca Paraván · Mg. Esteban Daniel Volentini
May 26, 2026

Context and Problem

Work Objectives

State of the Art and Platform Selection

Infrastructure and Deployment Architecture

Live Demonstration

Conclusions

Section 01

Context and
Problem

Current signing process at FACET

Problems

Administrative time

Human errors

No traceability

Inefficient storage

Electronic Signature or Digital Signature?

Meets

✓ Meets all the technical and legal conditions of Law 25.506 to be a Digital Signature

✗ Except: the certificate was not issued by a Certification Authority licensed by the State

Electronic Signature Valid in FACET's internal administrative scope

Before moving on to the demonstration, I want to clarify the legal framework of the system. Documenso does everything the law requires technically: it applies a mathematical procedure that uniquely identifies the signer, and guarantees the integrity of the document — any later alteration invalidates the signature. But Law 25.506 has an additional requirement to be considered a Digital Signature: Article 9 requires the certificate to be issued by a Certification Authority licensed by the State. We use a self-signed certificate, generated inside the institution — without that external backing. That means the system produces Electronic Signatures, not Digital Signatures. But that does not invalidate it: it has full administrative validity within FACET, for all its internal circuits.

Section 02

Work
Objectives

Design, implement and deploy a “turnkey” solution for managing and electronically signing PDF documents at the faculty

The proposal replaces that seven-step manual process with an automated four-step one. [PAUSE] Step one: single upload. The lecturer or student uploads the PDF to the system once. No downloads or email forwarding. [PAUSE] Step two: visual configuration. Directly in the web interface, they define who must sign and where each signature goes on the document. [PAUSE] Step three: Documenso's automation engine takes care of the rest — it notifies each signer in turn and manages the flow without manual intervention. [PAUSE] Step four: traceable output. The final document is signed, with a cryptographic seal, publicly verifiable, and stored in FACET's infrastructure.

Specific Work Objectives

Survey
& Selection

Architecture
& Policies

Pilot
Implementation

Documentation
& Transfer

Section 03

State of the Art and
Platform Selection

Market Overview: SaaS Solutions

			Adobe Sign
Cost per userannual plan	$25 USD/month	$25 USD/month	$24 USD/month
Sending limit	100 envelopes/yearper user	Unlimited	150 envelopes/yearper user
Data residency	Own infrastructureAWS · Azure	AWS	AWS · Azure
20 usersestimated cost	$500 USD/month$6,000 USD/year	$500 USD/month$6,000 USD/year	$480 USD/month$5,760 USD/year

Market Overview: Open Source Solutions

documenso / documenso

★ 13.1k

“The open source DocuSign alternative.”

TypeScript

nextjs postgresql self-hosted pades-standard pdf-signature document-signing

docusealco / docuseal

★ 16.9k

“Open source DocuSign alternative. Create, fill, and sign digital documents.”

Ruby

ruby-on-rails vue self-hosted e-signature pdf-signature document-signing

Comparison: Documenso vs DocuSeal

	Documenso ✓ Selected	DocuSeal
Role-Based Access Control (RBAC)	✓ Community Ed.	✕Enterprise Edition
Google login (SSO)	✓ Community Ed.	✕Enterprise Edition
Custom branding	✓ Community Ed.	✕Enterprise Edition
Tech stack	Remix (full-stack)PostgreSQL	Ruby on Rails + Vue.jsPostgreSQL
License	AGPL-3.0	AGPL-3.0

Why Documenso?

Organizational Model Aligned to FACET

Documenso

analogous

FACET

A user can belong to multiple departments and has access only to the documents of each one.

Why Documenso?

Integrations with External Services

MinIO

S3-compatible storage for signed PDFs.

Brevo

SMTP relay for notifications. Free tier: up to 300 emails/day.

Google login

OAuth 2.0 with Google Workspace UNT: access with an institutional account.

Section 04

Infrastructure and
Deployment Architecture

Infrastructure and Deployment Architecture

Key Infrastructure Concepts

Server 1

Proxmox VE

Open-source virtualization environment

Full Virtualization

KVM / QEMU

Containers

← in use

LXC: Linux Container

8 vCPU · 8 GB RAM · 50 GB disk

Inside the LXC

Coolify

PaaS

Traefik

Reverse Proxy

Frontend

Backend

Database

Server 2

TrueNAS

Disk management

MinIO

Object Storage S3

General Architecture

Documenso Stack

Storage Sizing

2 TB — allocated quota

16 TB — remaining space (TrueNAS)

300

emails/day · Brevo limit

÷ 6 notifications per procedure

procedures/day

× 2 PDFs × 10 MB

1 GB/day

projected daily growth

× 1,825 days · 5 years

1.825 TB

projected maximum volume

2 TB

Quota allocated in MinIO
safety margin ~10%

Once the service architecture was resolved, the next step was to size the object storage in MinIO. We did not assign resources 'by eye': the calculation starts from the real operational limit of the email provider. Brevo allows 300 emails per day. An average procedure requires 6 notifications, which gives a ceiling of 50 documents per day. Each procedure generates 2 PDFs of 10 MB on average, that is 20 MB per procedure, which gives 1 GB of daily growth. I configured a 5-year ILM retention policy for regulatory reasons — 1,825 days times 1 GB gives us a projected 1.825 TB. That is why I assigned a strict 2 TB quota, with a 10% margin. And as you can see in the chart, those 2 TB represent barely 11% of the TrueNAS server's 18+ TiB at the faculty.

Backup and Retention Policies

Database

PostgreSQL

Frequency: daily — 3:00 AM
Content: PostgreSQL .dmp file
Retention: 30 days

Configuration

Docker Compose + .env

Frequency: daily — 4:00 AM
Content: compose + .env + certificate .p12
Retention: 180 days

Operating On-Premise means the faculty assumes full responsibility for continuity. I designed the strategy in two domains. First, the database: PostgreSQL runs an automatic logical dump every day at 3 in the morning, into an isolated MinIO bucket. Retention is 30 days with Object Lock in governance mode — that is, nobody can delete or modify those dumps during that period. Maximum RPO of 24 hours, and restoration is done directly from the Coolify interface. Second, the configuration: a bash script runs every day at 4 in the morning — one hour after the dump — and packages the docker-compose files, the environment variables and, fundamentally, the Base64-encoded .p12 signing certificate. That certificate is what gives each generated signature its institutional identity. Without it, even with the database recovered, I cannot issue new signatures. With this backup, I rebuild the entire environment in minutes.

Testing and Results

System Performance

CPU and RAM during a burst of 5 documents

Netdata — burst of 5 concurrent documents

Memory (RAM)

Allocated 8 GB

Peak 1.33 GB

Free 83.7 %

Processor (CPU)

Allocated 8 vCPUs

Peak 12.5 %

Free 87.5 %

At rest, the four containers consume only ~500 MB of RAM.

Section 05

Live Demonstration

Live Demo

Design, Implementation and Deployment of an On-Premise Electronic Document Signing System for FACET

Table of Contents

Context and
Problem

Electronic Signature or Digital Signature?

Work
Objectives