Security and backups

Last updated: 9 October 2026

Where your data is kept, how it is backed up, how accounts are protected, and what we do when something goes wrong. Everything on this page describes how the service runs today.

Where your data is

The application, the database and the click analytics run on a netcup server in Amsterdam, in the Netherlands.
Email is sent and received by our own mail server, hosted with Hetzner in Helsinki, Finland.
Backups are stored with Hetzner in Germany.

All three are in the European Union. Payments are handled by Paddle, so card numbers never reach our servers. The Privacy Policy lists every company that receives any data, and what each one receives.

Backups

A backup runs every night. It covers:

the database: accounts, workspaces, links and their settings;
the click analytics;
the TLS certificates of customers' own domains;
uploaded files, such as attachments to support requests.

Each backup is encrypted on our server before it is sent. The server holds only the key that encrypts; the key that opens a backup is kept somewhere else, so the storage provider cannot read the backups, and neither can the server that made them.

The backups go to a different provider, in a different country, from the server they protect. The last seven nightly copies of the database are kept. A backup is recorded as successful only after the archive has been read back and the uploaded size matches, and a failed backup sends us an email.

Restoring

We test that backups can be restored. The test loads the latest production backup into an empty database on a separate machine and counts what came back. The most recent test was on 8 October 2026: that night's backup restored completely in under ten seconds.

Backups are nightly, so if the server were lost entirely, changes made since the last backup could be lost: at most 24 hours of new links, edits and clicks. Redirects are answered from memory for speed, and that store is rebuilt from the restored database, so a restored link redirects again without any action from you.

Moving the service to a new server is a written procedure: install, restore the latest backup, rebuild the redirect store, change DNS. We do not promise a fixed recovery time.

Your account

Passwords are stored only as bcrypt hashes. Nobody here can read your password.
An API key is shown once, when you create it. We keep a hash of it, and you can revoke a key at any time.
Every page and every redirect is served over HTTPS. A domain you connect gets its own certificate, issued and renewed automatically.
Each person in a workspace signs in as themselves and has a role that limits what they can change. On the Business plan an audit log records who changed what.
Sign-in attempts are rate limited.
You can delete your account yourself, without asking us.

People who click your links

Clicks are counted on the server, without cookies, and a visitor's IP address is not stored. Privacy and cookies explains what is recorded for a click.

If something goes wrong

We have a written procedure for security incidents. If an incident affects personal data that we process for you, we tell you without undue delay and within 48 hours of becoming aware of it, which is a commitment in section 14 of our Terms. Where the law requires it, we also notify the data protection authorities within 72 hours.

Reporting a security problem

If you have found a vulnerability, write to abuse@urlicer.com. The same address is published at /.well-known/security.txt. To report a short link that is being abused, use the report form.

If Urlicer closes

Section 12 of the Terms sets out what we owe you in that case: at least 180 days of notice, export open on every plan, links on ivi.to redirecting for at least 12 months after the closing date, and a redirect server published under the MIT licence. What happens to your links explains it in plain words.

Security testing

We run our own penetration tests, using AI tools. The most recent was on 8 October 2026. It ran against a separate copy of the service, with a second account acting as the attacker, and was followed by a read-only check of the live site from outside.

It covered:

whether one workspace can reach another's data, through the app and through the API;
sign-in and sessions;
the admin interface;
the requests our server makes to addresses that users supply;
injection and cross-site scripting;
the redirect path;
billing and plan limits;
rate limits and the other abuse controls;
which ports and services can be reached from the internet.

It found no vulnerability that could be exploited. One hardening change came out of it, a stricter check on the addresses a link may point to, and that change is in place.

What is not in place

No outside firm has tested the service, and we hold no SOC 2 or ISO 27001 certification.
Two-factor sign-in and single sign-on (SAML or OIDC) are not available.

Data processing terms

For the data of people who open your links, we act as your processor. Data processing terms lists what we process, for how long, and with which sub-processors.

Questions about anything here: privacy@urlicer.com.