Most teams start with a hosted product and never look back. Some, though, reach a point where running the tool on their own server makes more sense. This post sets out what to think about before you start, so you can decide with the practical details in front of you.
Why some teams want to host on their own server
The reasons vary, but they usually come down to control. Some organisations have internal rules about where software runs and where data is kept. Others already run a server, have people who manage it, and would rather add one more tool to that setup than rely on another external service. Some charities and small public-facing teams prefer to keep their help content within infrastructure they already maintain.
Self-hosting is not automatically better or cheaper. It moves responsibility to you. Before you choose it, be clear about why you want it. If the answer is "we want to know exactly where things run", you are in a good position. If the answer is "it sounds more professional", take a step back and compare the work involved with what you would gain.
What you need: Docker or Coolify, and somewhere to run it
HandHoldly can be hosted on your own server using Docker or Coolify. If you already use either, the setup will feel familiar. If you do not, it is worth learning the basics before you commit.
You will need:
- A server or virtual machine with enough memory and disk space for the application and its database
- Docker installed, or Coolify set up on a server you control
- A domain name and a way to serve it over HTTPS
- Someone who can read a configuration file and check that a container has started properly
Think about where the server sits, too. A machine in the same region as your users will usually feel more responsive, and it is easier to keep track of if it lives in a place your team already manages. Write down who has access to the server and how they sign in. That list is useful later, when someone leaves or a password needs changing.
Where recordings go: any S3-compatible storage
Walkthrough videos are the largest files the tool produces, so storage needs thought early. HandHoldly can keep recordings in any S3-compatible storage. That gives you a choice: you can use a bucket from a cloud provider you already have an account with, or run your own S3-compatible service if your organisation prefers that.
A few practical points to settle before you start:
- Create a dedicated bucket for recordings rather than sharing one with other systems. It makes permissions and clean-up easier.
- Check how much storage a typical walkthrough uses. A short product tour is small; a long, high-resolution series adds up quickly.
- Decide who can read the bucket. Recordings should only be reachable through the tool, not left open to anyone with the link.
- Think about retention. If a feature changes and an old video is no longer accurate, you will want a clear way to remove it.
It is also worth testing the connection with a single recording before you rely on it. Find out now that a misspelt bucket name or a wrong region setting is the cause of a failure, not during a busy release week.
Who looks after updates and backups
This is the question that matters most, and it is the one teams most often leave until later. When you self-host, you are responsible for the running copy. That means someone needs to own:
- Updates. New versions need to be pulled and applied. Decide who checks for them, who tests them on a copy first, and who makes the call to roll out.
- Backups. The database holds your scripts, steps and settings. Recordings sit in your storage, so back those up too, or confirm that your storage provider's arrangements meet your needs.
- Restores. A backup you have never tried to restore is a hope, not a plan. Practise a restore on a spare server at least once.
- Monitoring. Someone should notice if the server runs out of disk space or the application stops responding.
Name an owner for each of these. A shared responsibility with no named person tends to become nobody's job. If your team is small, consider whether a single person can cover this alongside their other work, and what happens when they are on leave.
HandHoldly's own scheduled nightly re-checks still run against your walkthroughs. When a step no longer matches the live product, the tool fires your webhooks and emails the owners, naming the step. Make sure those notification routes lead to people who will act on them.
Stored logins are encrypted: what that means in practice
Where a walkthrough needs to sign in to your product, HandHoldly stores those login details encrypted. That is one of the security points we can describe plainly. It means the stored credentials are not kept as readable text in the database.
What it does not do is remove your own responsibilities. Encryption protects stored logins, but it does not decide who can reach the server, how the server is patched, or who holds the keys needed to read the data. Treat the login details your walkthroughs use as you would any other sensitive credential:
- Use a test account with the smallest sensible permissions, not an administrator account.
- Keep the server itself locked down and up to date.
- Limit who can open the admin area of the tool.
- Remember that personal data can appear in recordings. The tool blurs personal data in the video, screenshots and article, but check the output before you publish it.
If your organisation has specific security or data protection requirements, take them to your own IT or security adviser. This post does not replace that conversation.
A short pre-launch checklist
Before you move from testing to real use, check these points:
- You know why you are self-hosting, and the reason still holds.
- Docker or Coolify is running on a server you control, with a domain served over HTTPS.
- A dedicated S3-compatible bucket is connected, and a test recording has saved and played back.
- One named person owns updates, another owns backups, and a restore has been tested on a spare server.
- Monitoring tells you when disk space or the application is running low.
- Notification webhooks and owner emails reach people who will act on them.
- Walkthrough logins use test accounts with limited permissions.
- Someone has reviewed a published video, screenshot and article for personal data.
- You have written down who can access the server and the admin area, and how they sign in.
- You have a plan for what happens when a team member leaves or changes role.
If you are still weighing up whether the tool fits your team, the quickest way to judge is to see it working. The how it works section shows how one script becomes a narrated video, a live guide and a step-by-step article, and how the nightly re-checks flag a step that has changed. Look at that first, then come back to this list with a clearer picture of what you need to set up.