Picture a QR printed on a restaurant’s table card: it opens the menu on a phone. If the restaurant leaves the service that created the QR, can it keep its cards? Yes, provided the link stored in the QR continues to open the menu.
Self-hosting means installing and managing software yourself, instead of using an online provider’s installation. With QR codes, you can use it to create the images or to run the links they open. To understand the difference, follow a customer opening the menu.
What happens when someone scans the QR?
In our example, the QR contains a web address. The phone reads that address, then opens it. There are two possible routes.
The QR goes directly to the restaurant’s website. It might contain https://restaurant.example/menu. The phone opens that page. The software that drew the QR takes no further part: once the image is saved, the generator does not need to remain available.
The QR goes through a link service first. It contains an address supplied by that service, which then sends the visitor to the menu. Automatically sending someone to another page is called a redirect. That service must keep working for the customer to reach the menu.
Your website must stay available.
The link service must stay available too.
This extra step is how dynamic QR codes change destination: the service can send the next visitor to a different menu. The QR image stays the same; the page the service sends people to changes.
If the QR opens your website directly, you can also update the page’s contents while keeping its address. Changing the dishes on restaurant.example/menu does not require a new QR.
What changes when you create the QR yourself?
Software installed on your computer can create the image from a link you give it. You keep the file and can print it. That task alone does not require running a permanent online service.
We checked this by creating three QR codes with network connections blocked during generation. All three images contained the intended links. This does not make the pages available offline: a customer still needs a connection to view a menu on the web.
You can also install a generator on a server, a computer that can be accessed remotely, so your team can use it. You then manage the installation and access to it.
In both cases, the link you choose determines who you depend on. Creating a QR yourself with a provider’s address does not put that address under your control. An online generator can also create a QR that goes directly to your own website.
The key question: who owns the address?
Back to the restaurant. If its QR contains an address belonging to the provider, the restaurant cannot decide on its own to run that address elsewhere. Downloading the image or the list of menus does not transfer the address.
There is another option: use the restaurant’s own address, even if a provider runs the links. The domain name is the part that identifies the website, such as restaurant.example. It can be registered to the restaurant, which keeps access to its settings.
That makes moving the service to another host possible, provided the links can be transferred. A host is the company providing the computer on which the service runs. Owning the domain and running everything yourself are separate choices.
A printed QR always retains its original address. If that address ends in /menu, that exact address must work after the move. Creating a page at a different address does not update the cards already handed out.
How can you keep the QR codes when switching services?
Keep the address the phone reads and make sure it can open the right page. If you use redirects, the replacement service needs the list saying where each link should send visitors. For example: “the menu link opens this page; the contact link opens that one.”
To test this mechanism, we created three QR codes. We stopped the small service running their links, then started its replacement. At first, it did not recognise any of the links: the pages could not be found. After loading a saved copy of the list, all three links worked again. We then changed the page attached to one link without changing its QR image.
The test shows why that backup matters. It ran on a single computer, without moving a real public website or scanning with a phone. The steps and files are available in the sources. A real move also requires routing visitors to the new server and setting up its secure HTTPS connection.
Before choosing a provider, check that you can retrieve your links and use them elsewhere. An “export” button alone does not guarantee this: you need to know what the file contains and try importing it into the replacement service.
What do you have to maintain yourself?
If you run the link service yourself, someone must look after it. The software needs to remain available when customers scan the codes. That includes:
- renewing the domain name to keep the address;
- installing updates and protecting administrator access;
- backing up the link list and checking that you can recover it after an outage;
- monitoring errors and responding when the service stops.
Software such as Shlink can manage these links. Installing it does not remove the maintenance work. We read Shlink’s documentation without installing or testing the software; the technical details are collected in the sources.
If you also want to keep scan history, check its backup separately. Restoring links does not mean historical analytics will be recovered too.
Which option fits your needs?
You only need a QR pointing to your website. An image containing your page’s address directly may be enough. You can create it with a local tool or a free generator. Keep the page available at that address.
You want to change which page opens after a scan. A link service can handle that. If you want to be able to switch providers later, look for a service that accepts your own domain and test how to transfer its links. You can delegate the operation while keeping your address.
You want to administer the service yourself. Self-hosting is an option if someone can install it, maintain it and fix an outage. Their time is part of the cost. Our pricing comparison covers hosted plans; it does not price that maintenance for you.
Before printing a large batch, try it with one QR. Check the link stored in the image, then what you would need to keep if you left the service. That is easier to sort out before handing out the restaurant’s cards.
Sources and technical test details
The test ran on November 3, 2026 with three links: /menu, /guide and /contact.
| Stage | Observed result |
|---|---|
| Original service running | Three HTTP 302 redirects, followed by three destination responses of 200. |
| Original service stopped | Connection refused by that instance. |
| Replacement service, empty database | Three 404 errors: the links are unknown. |
| Backup restored, same hostnames and paths | All three links reach their destinations again. |
Destination for /menu changed | The same QR leads to the new page. |
| Links recreated under a different hostname | The three original addresses return 404; the new control address works. |
The PNG images remained identical, byte for byte. Apple Vision decoded them before and after the experiment. The client sent requests explicitly to the local server with the requested hostname. Two successive instances on the same Mac used separate SQLite databases. Public DNS, HTTPS certificates, browser caching, Shlink software and physical scans were not tested.
- Full results, reproducible script and Apple Vision decoder. The script uses Python’s HTTP server, which is not recommended for production. The test does not measure performance, long-term availability or one product’s superiority.
- Segno’s official documentation: PNG/SVG generation library. Version used: 1.6.1, with Python process network connections blocked during generation.
- IETF, RFC 9110, HTTP origins and 302 response. Test redirects used
Cache-Control: no-store. The.testand.exampledomains are reserved by RFC 2606; example addresses are not websites to visit. - Shlink documentation: link management through an API or command line, with a separate web client. Its Docker persistence guidance reserves the bundled SQLite database for experimentation and calls for an external database in production.
- Shlink import: CSV requires the short code and long URL, with an optional domain; direct import from another instance requires the source to remain available. That migration does not replace an independent backup. HTTPS reverse-proxy configuration: the certificate still needs configuring. Documentation consulted November 3, 2026.
Share this article