DEV Community: iMonitor Software

Employee monitoring reading list: nine languages, seventeen guides each

iMonitor Software — Sat, 31 Oct 2026 16:59:51 +0000

We write about employee monitoring in nine languages — not translated, but written for each market. This is the index, so you can jump straight to your language instead of scrolling through a hundred posts.

The nine language guides

Español — 17 guías
Deutsch — 17 Leitfäden
Français — 17 guides
Italiano — 17 guide
Português — 17 guias
日本語 — 17 ガイド
한국어 — 17 가이드
Türkçe — 17 rehber
繁體中文 — 17 篇指南

What each language covers

The same seventeen topics, in this order:

Hybrid work: what monitoring should answer
BYOD: what may be recorded on a personal device
Retention: how long to keep, and how to justify it
When an employee objects: the first hour
Work time and payroll accuracy
A 30-day rollout that does not break trust
What happens to monitoring data when someone leaves
Server and storage sizing, with the actual formula
On-premise vs cloud: five differences that matter
Counting keystrokes instead of recording content
Five cases where you should not buy this software
Reporting to management: three numbers, not screenshots
The three realistic ways monitoring data leaks
The five questions your team will ask
Companies without HR: who owns this
Three signals someone is leaving (and what data cannot see)
Four costs that never appear in the quote

The two pages that are not articles

Pricing and licensing — how per-seat perpetual licensing works, plus the FAQ we get most
What we record and what we do not — the six-section version, including the fields we refuse to collect

Why a separate host

The main site is on its own infrastructure; this is an independent mirror so the guides stay readable even when infrastructure has a bad day. Everything is static HTML, no tracking scripts, no cookie banner to dismiss.

If you are evaluating monitoring software, start with items 10 and 11 — they tell you fastest whether the product thinks the way you do.

General information, not legal advice.

The five questions your team will ask about monitoring (and answers that hold)

iMonitor Software — Sat, 31 Oct 2026 15:32:56 +0000

Announce monitoring and the same five questions appear, in the same order, almost every time. Having the answer written in advance — in the exact wording you will use in the room — removes about half of the conflict before it starts.

1. "Are you watching me?"

The answer that holds: "We record working time and which applications are used. We do not record what you type — we count keystrokes, never content."

Do not answer only "this is not surveillance". If you skip what is recorded, people fill the gap with the worst case. Name the fields.

2. "Does this affect my review?"

The honest answer depends on the policy — and that policy has to exist before installation, not after. If the data will appear in a performance conversation, say so. If it will not, write that down too: "this data is not used for sanctions; it is used to find process problems."

The failure mode is leaving it ambiguous and letting people assume the worst.

3. "Can I see my own data?"

Yes — and there should be a one-page procedure for asking, sitting next to the one for correcting an error. Refusing is the step that turns a management tool into a legal problem.

4. "What about outside working hours?"

"Activity outside your working hours is not recorded." And that has to be true in the configuration, not just in the presentation. Somebody will check.

5. "What if I use my own laptop or phone?"

The phone is out of scope. With BYOD, only work applications are covered — and you say which ones.

The worst possible answer

"If you have nothing to hide, you have nothing to fear."

It sounds like a defence and is heard as a threat. It also concedes the frame: that the purpose is suspicion. Change the frame instead — the system exists to answer a specific question: shifts that do not add up, overtime nobody approved, files leaving the company. Name the problem, not the suspicion.

One sentence that buys more trust than any policy

"If in three months we have not made a single decision with this data, we turn it off."

Almost nobody says it, which is why it works.

Before the announcement

Write the five answers down, in the language people actually speak at work
Decide, in writing, what the data will never be used for
Name who can see raw data versus the monthly report
Have the correction procedure ready before someone needs it

The announcement is a one-hour event. These five answers are what people repeat to each other for the next two years.

The nine-language versions of this piece are at imonitor-eam-guides.surge.sh — same structure, written for the local market rather than translated. iMonitor EAM is licensed per seat, on your own server.

General information, not legal advice.

Reporting monitoring results to management: three numbers, not screenshots

iMonitor Software — Sat, 31 Oct 2026 15:12:31 +0000

The first time someone brings monitoring results into a leadership meeting, they almost always bring screenshots. It is the most common mistake, and it fails twice: a screenshot cannot be compared to anything, and in a room it reads as surveillance rather than management.

The three numbers

1. Coverage. What share of the workforce is actually recorded, with the agent running? If it is 70%, the rest of the report is decoration. Coverage is the confidence interval on every other number.

2. Deviation rate. What share of person-days falls outside the expected pattern? Around 3% is healthy. 30% does not mean people are not working — it means the baseline is wrong, and the report is measuring your assumptions rather than their work.

3. Time to conversation. How many days pass between an anomaly appearing and someone talking to that person about it? If the answer is "never", the system produces suspicion and nothing else. This is the number that predicts whether the rollout survives year two.

Why screenshots are the wrong instrument

No context. A capture does not show that the person covered two roles for three weeks, or that the ticket queue tripled.
No comparability. One frame cannot be trended, so it cannot support a decision, only an impression.
No scale. Nobody reviews 200 captures. The one selected for the meeting is always the most striking, not the most representative.
It invites the wrong conversation. The meeting drifts to "is this legal / is this spying" instead of "do we need a second shift".

Compare months, not people

"Weekly active hours in support dropped from 6.1 to 5.4 after the shift change" leads to a staffing decision.

"Marta averaged 4.2 and Paul 7.8" leads nowhere, because you cannot act on it without first deciding whether the difference is skill, workload, or equipment — and that decision needs data you do not have.

Team-level trends survive scrutiny. Individual comparisons invite disputes you will lose on procedure, not on facts.

A one-page format

Three short paragraphs:

What changed — one sentence, dated.
Which number shows it — the trend, not the single frame.
What was decided — the action, the owner, the date to review.

If there is no decision, the third paragraph does not exist, and the report should probably not be sent. Monitoring data that never changes a decision is a cost with a liability attached.

The mistake that ruins the data

If the first report is used to sanction someone, the second year of data will be false. People learn quickly which signal is rewarded, and they will produce that signal.

Say it in writing, on day one: what the data is for, and what it will not be used for. Then hold that line the first time it is inconvenient — that moment is what everyone is actually watching.

What to do before the first report

Agree the three numbers with whoever will read the report, before you collect anything
Fix the retention period for the report itself (it contains personal data)
State the aggregation floor — no group smaller than five people
Decide who can see the raw data versus the report

Ten minutes of agreement up front saves a year of arguments about methodology.

iMonitor EAM collects session and application metadata, file operations, USB events and keystroke counts on your own server — enough to produce the three numbers, without the content that turns a management report into an investigation.

General information, not legal advice.

The fields a monitoring agent should refuse to collect

iMonitor Software — Sat, 31 Oct 2026 15:01:53 +0000

Most monitoring agents are built by adding features. The hard part is subtraction: deciding what the agent will not collect even though it technically could.

That list is not a legal nicety. It determines the blast radius of a breach, the amount of data you must disclose, and whether an administrator can defend a decision six months later.

What to collect (and why)

Field	Why it is defensible
Session start / end / idle transitions	Answers "was the desk staffed", no content
Application and window titles	Answers "was the licensed tool used"
File copy / move / print events (path + size)	Data movement, not content
USB insert and file write	Exfiltration signal
Keystroke count per interval	Workload intensity without content

Every one of these can be explained in a sentence to the person being recorded. That is the test: if the explanation needs a paragraph of justification, the field probably should not exist.

What to refuse

Typed content. Full keystroke logging captures passwords, personal messages, medical information, and everything a customer said. Store counts, not text.
Clipboard contents. It is the single most sensitive buffer on a machine. Store "copy event in app X" if you must, never the payload.
Screen recording by default. Screenshots on an interval are already intrusive; continuous video multiplies storage by 20–60× and captures whatever happens to be on screen, including unrelated people.
Webcam and microphone. Almost never justified in an employer-employee context.
Location outside work hours. Company device or not, tracking after hours is a different legal animal.
Personal device content. If BYOD is allowed, scope to work applications, not the whole machine.
Chat and mail bodies. A separate module, off by default, with its own retention.

Why "we might need it later" is the wrong default

Three concrete costs:

Breach scope. Content you never collected cannot leak. A breach report that says "session metadata" reads very differently from one that says "keystrokes and clipboard".
Disclosure obligations. More categories means more jurisdictions where you must notify, and longer incident reports.
Insider risk. Every extra field is something an administrator can misuse, and something you must audit access to.

Make the refusal visible in the product

A refusal that lives only in a policy document is not a product decision. Put it in the UI:

A "what we do not record" block on the compliance page, in the language of the buyer
A settings screen where the sensitive modules are off by default and labelled as exceptions
An audit log of who enabled what, with a date

If a customer asks "can it capture keystrokes?", the honest answer should be "counts, not content" — and the interface should say so before the salesperson does.

The exception path

Some organisations genuinely need content-level audit: regulated environments, a specific leak investigation, shared machines handling sensitive data. Those cases need:

Written authorisation with a named approver
A time bound (start and end date)
Access logging, so the audit is itself auditable
A removal step when the case closes

That is a very different posture from a toggle that stays on for the whole company for three years.

A test you can run before buying

Ask the vendor for the field list of what the agent sends, then ask them to strike out anything they would not want recorded about themselves. The size of the remaining list tells you what kind of product it is.

We build iMonitor EAM with exactly this list: session and application metadata, file operations, USB events, keystroke counts, on-demand screenshots — and the content modules off by default, on your own server, with a retention job that actually runs.

General information, not legal advice.

A support desk on one small server: sizing, backups and the boring parts

iMonitor Software — Sat, 31 Oct 2026 14:59:12 +0000

Most "run your own help desk" guides stop at docker compose up. The interesting part starts three months later, when the disk fills up or a restore has to actually work.

Here is the unglamorous version, for a team of three to ten.

What actually consumes disk

Component	Growth	Notes
Message bodies + metadata	slow	thousands of tickets ≈ a few hundred MB/year
Attachments	fast	screenshots and PDFs dominate
Search index	medium	rebuildable, can be excluded from backups
Logs	slow but relentless	cap at 30 days, rotate
Database WAL / binlogs	bursty	the usual suspect when disk "suddenly" fills

Rule of thumb: plan for attachments to be 10× the database. A 2 GB database usually comes with a 20 GB attachment store.

A sizing that survives a year

For 5 agents, ~60 tickets/day, average 1.5 MB of attachments per ticket:

60 × 1.5 MB × 365 ≈ 33 GB/year of attachments
database + index         ≈ 3-5 GB/year
logs (capped)            ≈ 2 GB
------------------------------------------
one year                 ≈ 38-40 GB

So: 80 GB of disk with retention pruning, or 200 GB if you keep attachments forever. Both are one cheap VPS.

The three cron jobs that matter

# 1. logical backup, compressed, off the same disk
0 2 * * *  pg_dump -Fc app | gzip > /backup/db-$(date +%F).dump.gz

# 2. attachments: rsync to a second location, not a tarball
30 2 * * *  rsync -a --delete /data/attachments/ /backup/attachments/

# 3. prune, with a count in the log so you can prove it ran
0 3 * * *  find /backup -name 'db-*.dump.gz' -mtime +14 -delete | wc -l

Three details that save you later:

pg_dump -Fc, not a raw file copy. A copied data directory from a running server is not a backup.
rsync attachments, do not tarball them. Restoring one file should not require unpacking 20 GB.
Log the count. When someone asks "is the backup running?", the log answers.

The restore drill

Once a quarter, on a scratch machine:

Create an empty database, pg_restore last night's dump
Point the app at it, start it
Open a six-month-old thread, download one attachment, send one test reply
Note the elapsed time

If that takes more than an hour, your restore procedure is a project, not a procedure.

Mail is the part people forget

The app is not the only thing that breaks. If inbound mail flows through the same box, an outage means customers get bounces and you learn about it two days later.

Two options that both work:

MX at an independent provider, forwarding into the app over IMAP/SMTP. Mail keeps arriving during app downtime.
SMTP relay for outbound only, so deliverability does not depend on your server's IP reputation.

Do not put inbound mail on a hostname whose DNS lives inside the app server.

Backups are not the same as portability

A database dump restores your installation. Portability means you can also leave:

A per-ticket export (JSON or CSV with bodies and attachment paths)
Attachments stored under stable, guessable paths
No proprietary blob format for the search index

Test the export once. If it produces a zip you can open on a laptop, you are not locked in.

What I would not bother with at this size

Kubernetes. One compose file and a systemd unit is easier to debug at 2 a.m.
Read replicas. At 10 agents, the database is idle most of the day.
Object storage for attachments unless you already run it — a mounted disk with rsync is fine, and simpler to restore.
Elasticsearch. Postgres full-text search handles a few hundred thousand messages without complaint.

The minimum viable runbook

One page, printed and taped inside a cupboard:

Where the server is, and its IP (not only the hostname)
Where DNS is managed, and who can change it
How to restart the app, and how to tell it worked
Where backups land, and how to restore one
The escalation channel when the app is down

If the person who set it up is on holiday, that page is the difference between a 20-minute fix and a lost day.

Onsites AI ships as a compose stack — app, Postgres, queue worker, optional mail fetcher — with the self-hosting notes covering exactly the parts above. Free for the first three seats if you want to measure your own ticket volume before sizing anything.

When your vendor vanishes: a practical checklist for owning your support data

iMonitor Software — Sat, 31 Oct 2026 14:55:57 +0000

A vendor outage is annoying. A vendor disappearing is a business event. The difference is not how long the downtime lasts — it is whether you can get your data and your domain back.

Here is the checklist I would run against any tool that holds customer conversations.

1. Can you export everything, in a format you can read?

Not "we support export" — ask for a sample file. Three questions:

Does it include message bodies or only metadata?
Does it preserve attachments, or just filenames?
Does it preserve threading (which message answered which)?

A CSV of ticket titles is not an export. If the demo cannot produce a zip with bodies, attachment files and thread structure, assume you cannot leave.

2. Is your domain yours, independently?

The single most common failure: the domain's nameservers are hosted inside the same infrastructure as the product. When that box dies, DNS dies, so mail bounces and you cannot even re-point the domain to a new host — you have no reachable nameserver to edit.

Check in 30 seconds:

dig +short NS yourdomain.com
for ns in $(dig +short NS yourdomain.com); do echo "$ns -> $(dig +short A $ns)"; done

If all nameservers share one IP, that IP is a single point of failure for your entire company, not just the product.

3. Can you still read your mail if the tool is down?

Support mail usually lands in the tool. If mail delivery depends on the tool's MX records, an outage means customers get bounces — and you find out days later from a customer who gave up.

Keeping MX at an independent provider (or at least a provider you control separately) means mail keeps arriving while the app is broken.

4. What is your break-glass path?

Write it down, once, on one page:

Where the origin IP is recorded (not only in DNS)
Who can change nameservers, and where that login lives
The last known-good export, and its date
Which channel you use to tell customers something is down

I have watched teams spend the first four hours of an outage looking for credentials. That is not a technical problem; it is a documentation problem.

5. Does the contract survive the vendor?

Ask for:

A stated export format and how long after cancellation it stays available
Notice period for shutdown or migration
Data deletion timeline, and confirmation they will not delete on day one

If none of that is in writing, you are relying on the vendor's goodwill at the exact moment they are least able to provide it.

6. Self-hosting is a spectrum, not a binary

Some teams need the whole stack on their own hardware. Most just need the data to be portable:

Level	What you run	What you keep
Cloud	Everything	Export + domain + mail DNS
Hybrid	App in cloud, data exports nightly	Database + attachments
Self-hosted	App, database and storage	Everything, including DNS

The middle option is underrated. You keep the convenience and remove the lock-in.

7. Test the restore, not the backup

A backup you have never restored is a hope. Once a quarter: export from the tool, import into a scratch environment, open a two-year-old thread, check one attachment opens.

Ten minutes, and it converts an untested assumption into a fact.

We build Onsites AI as a shared inbox with a Docker Compose deployment: app, database and queue on your own hardware, mail through any provider you like. The self-hosting notes are deliberately boring — they list what to prepare before the first install, including the parts above that decide whether a bad day becomes a lost quarter.

Two nameservers on one box: the outage that takes DNS and the website down together

iMonitor Software — Sat, 31 Oct 2026 14:50:17 +0000

A domain goes offline in two very different ways, and most small teams have only planned for one of them.

The first: the web server dies. DNS still resolves, browsers get a connection refused, someone restarts the box, everyone moves on.

The second: the nameservers die. Nothing resolves at all. Mail bounces, the marketing site disappears, the API looks like it never existed, and — worst of all — you cannot even reach the server to fix it, because you have no way to find it.

The second failure mode is entirely avoidable, and it is usually invisible until it happens.

The configuration that causes it

imonitorsoft.com.   NS   ns1.imonitorsoft.com.
imonitorsoft.com.   NS   ns2.imonitorsoft.com.
ns1.imonitorsoft.com. A  203.0.113.10
ns2.imonitorsoft.com. A  203.0.113.10   <-- same address

Two nameservers, one IP. Registrars accept this. It satisfies the "at least two NS records" checkbox. It provides exactly zero redundancy, because both nameservers are the same machine, and usually the same machine as the website.

When that box stops answering, the entire zone becomes SERVFAIL. Not "down" in the sense your monitoring notices — the domain effectively stops existing.

How to check yours in 60 seconds

# what the registry delegates to
dig +short NS example.com

# where those nameservers actually live
for ns in $(dig +short NS example.com); do
  echo "$ns -> $(dig +short A $ns | paste -sd, -)"
done

# and ask a public resolver, not your own cache
dig @1.1.1.1 example.com A +short

If every nameserver resolves to the same IP, you have a single point of failure that will take the whole domain with it.

The fix, in order of effort

1. Move DNS to a provider that runs it as a product. Cloudflare's free tier is enough. You point the registrar at their nameservers and never host authoritative DNS on the same box as the website again.

2. If you must self-host DNS, split it. Two nameservers on two providers (or two regions), each with its own address. The registry's requirement exists precisely because one machine is not redundancy.

3. Keep the DNS provider independent of the hosting provider. When your host has a bad day, you want to be able to re-point the A record somewhere else in five minutes. If DNS lives inside the host, you cannot.

What this costs when it goes wrong

Not the server bill — the recovery time. When the domain does not resolve:

You cannot SSH by name; you need the IP written down somewhere
Customers cannot reach support to tell you the site is down
Certificate renewals and API callbacks fail silently
Search engines start dropping pages from the index after a few days
Every link you published for months points at a host that no longer answers

That last one is the expensive part. Content is recoverable — you have the source. Index position is not.

A small checklist

[ ] Nameservers resolve to at least two different addresses
[ ] DNS provider is not your hosting provider
[ ] The origin IP is written down somewhere outside the infrastructure
[ ] dig @1.1.1.1 yourdomain.com works from a network you do not control
[ ] You have a copy of the zone file exported somewhere
[ ] Monitoring checks resolution, not just HTTP

That last item matters more than it looks. An HTTP check on a hostname silently fails when DNS fails — and if your monitor runs inside the same network, its cache may still answer, so it reports green while the world sees SERVFAIL.

We run Onsites AI with a self-hosted option, and this is exactly why the deployment docs insist on external DNS rather than putting it on the app server. If you are setting up a small support stack, the self-hosting notes cover the boring parts that decide whether you survive a bad day.

What an on-premise monitoring server actually stores (and how to size the disk)

iMonitor Software — Thu, 29 Oct 2026 06:46:38 +0000

Every on-premise monitoring pitch ends with the same question from IT: "fine, but how much disk?" The honest answer is a formula, not a number. Here is what actually lands on the server and how to estimate it.

What gets stored

A typical deployment writes five kinds of rows:

Table	One row per	Typical size
`sessions`	login / logout / idle transition	~200 bytes
`app_usage`	app or site, aggregated per interval	~150 bytes
`file_events`	copy, move, delete, print, USB write	~400 bytes + path
`screenshots`	one captured frame	150–400 KB
`audit_log`	who viewed which recording	~200 bytes

The first three are metadata. The fourth is the only thing that grows fast.

The sizing formula

disk ≈ endpoints × captures/day × avg_capture_size × retention_days
     + endpoints × metadata_per_endpoint_per_year × years

A concrete case — 200 endpoints, one capture every 10 minutes (≈48/day), 250 KB average, 30 days:

200 × 48 × 250 KB × 30 ≈ 72 GB

Metadata for the same fleet is a rounding error by comparison: tens of GB per year, not hundreds.

Video changes the order of magnitude

Screen recording, if you enable it, costs 20–60× the equivalent duration in screenshots depending on resolution and codec. Two consequences:

Enable recording per-group, not per-tenant. Most organisations need it for a handful of regulated roles.
Cap recording duration in the policy, not in the storage layer. Disk-full is a much worse failure than "recording stopped at the limit".

Retention must be enforced by the system

A retention policy in a PDF is not retention. The database needs a scheduled delete with three properties:

Per-table windows — screenshots expire faster than file events, which expire faster than payroll-relevant time records.
Legal hold override — one flag on a case that suspends deletion for exactly those records, with an owner and an end date.
A dry-run mode — so you can see what would be deleted before turning it on.

-- pseudocode for the nightly job
DELETE FROM screenshots
WHERE captured_at < now() - interval '30 days'
  AND thread_id NOT IN (SELECT id FROM legal_holds WHERE released_at IS NULL);

Run it with LIMIT batches during business hours, and log the count. The log is what proves the policy is real.

Backups are the hidden doubling

The estimate above is live data. Backups typically double it, and a second copy off-site doubles it again. If the number you quoted to management was 72 GB, the actual infrastructure number is closer to 150–200 GB once retention snapshots exist.

Network is rarely the bottleneck

Agents that only send metadata use almost nothing. Screenshots are compressed and sent on intervals. The real spike happens when an administrator opens a playback session — that is a burst of image reads, not sustained WAN traffic.

Two things worth deciding early

Where does the database live? On the same box as the screenshot store, you get one failure domain and one restore procedure. Separate them and you get scale, plus two things to back up.
What is the growth assumption? Sizing for today's endpoint count is the classic mistake; size for the fleet you expect when the licence renewal comes around.

This is the model iMonitor EAM ships with: server and database on your own hardware, keystroke counts rather than content, per-module retention, and a 15-day trial that is enough to measure your own capture rate before committing to disk. More at imonitorsoft.com.

Modelling a shared inbox: why the message is the primary key, not the conversation

iMonitor Software — Thu, 29 Oct 2026 04:53:34 +0000

Every shared-inbox implementation starts with a conversations table and ends up regretting it. Here is the model that survives contact with real support traffic.

The problem with conversation-first

A conversation is a derived thing. It is what you get after you decide which messages belong together. If you store conversations as the source of truth, every new channel forces you to write merge logic that mutates the conversation rows — and merges are the one operation that must never lose data.

Messages, by contrast, arrive once and never change. They are the natural primary key.

The model

-- the immutable fact
messages(id, channel, external_id, direction, sent_at, body, raw)

-- who it came from (may be shared by many messages)
contacts(id, email, phone, name)

-- the derived grouping, rebuildable at any time
threads(id, subject_key, opened_at, closed_at)

-- the link, append-only
thread_messages(thread_id, message_id, added_at, reason)

Three properties matter:

thread_messages is append-only. A merge inserts rows; it never rewrites history. If the merge was wrong, you can split by deleting the link rows — no data lost.
Threads can be rebuilt. Delete every row in threads and you can regenerate them from messages plus your merge rules. That is the test for whether your grouping logic is a projection or a tangle.
reason is stored. "Same contact, 4h window" vs "manual merge by ana" answers the question every support lead eventually asks: why are these two emails in one thread?

Identity is the hard part

The same person writes from ana@company.com, then from a personal address, then from a second work address after a rebrand. Matching on the exact string gives you three contacts and three threads.

A workable compromise:

Exact match first (email, phone, then channel-specific ID)
Then a domain-and-name heuristic that suggests a merge rather than performing one
Never auto-merge across organisations

The suggestion queue is boring, and it is what keeps identity resolution honest: a human confirms the ambiguous cases rather than a regex.

Delivery state belongs to the message, not the conversation

Outbound mail can be queued, sent, delivered, bounced, complained. That lifecycle is per message and per recipient. Storing "the conversation was sent" hides the one case that matters: one of three recipients bounced.

message_delivery(message_id, recipient, state, updated_at, provider_id)

With that table, "did they get it?" is a query instead of a support escalation.

What this buys you

Channel integrations become writers of messages, not reimplementations of threading
AI summarisation or tagging attaches to messages/threads as a separate table, never mutating the record
Deleting a thread is a policy operation (remove link rows + messages), so retention rules become enforceable
Migration to a new database is a row copy, not a logic rewrite

The one thing to get right early

Make messages.external_id unique per channel and dedupe on insert. Every provider retries webhooks. Without that constraint you will ship duplicate replies, and duplicate replies are the failure customers remember.

This is the shape we use in Onsites AI — a shared inbox, CRM and light invoicing for teams of three to thirty, self-hostable or cloud. The schema notes above are portable either way.

Self-hosting a support desk: what actually changes when customer data cannot leave the building

iMonitor Software — Wed, 28 Oct 2026 17:44:13 +0000

"Can we self-host it?" is usually asked late, after a team has already started using a cloud tool. The answer changes more than the deployment diagram.

1. Backups become your problem, and that is the point

In a hosted product, backups are a line in a contract. Self-hosted, they are a cron job, an off-site copy, and a restore you have actually tested. Teams that skip the restore test discover the problem at the worst moment.

The upside: the backup never leaves infrastructure you control, which is often the original reason for self-hosting.

2. Upgrades are a decision, not an event

Cloud products upgrade on the vendor's schedule. Self-hosted, an upgrade is a maintenance window you choose — and can postpone during a busy week. That flexibility is real, and so is the cost: someone has to read the changelog.

A practical rule: pin the image tag, upgrade monthly, keep the previous tag for a one-command rollback.

3. Attachments change the storage question

Conversations carry files. In the cloud, those files sit in someone else's object storage. Self-hosted, they sit on your disk or your S3-compatible bucket, which means retention, quotas and encryption are yours to define — and yours to get wrong.

4. Email is the hard dependency

A support desk that cannot send email is not a support desk. Self-hosting the app is easy; self-hosting reliable outbound email is not. Most teams run the app themselves and still send through a transactional provider. That is a reasonable split: the conversations stay inside, the delivery goes through a specialist.

5. What you actually gain

A retention policy you can enforce rather than request
Data residency answered with an IP address instead of a document
Access control that maps to your own identity provider
The ability to run on a network with no outbound internet, if that is the requirement

6. What you actually give up

Vendor-managed uptime
Someone else testing upgrades before you see them
Support that assumes they can see your database

A workable middle ground

Run the app in Docker with three services (app, database, queue), a nightly dump to an off-site bucket, and outbound email through a transactional provider. That covers most self-hosting requirements without turning into a platform team.

This is the model Onsites AI ships with: a Docker Compose deployment for the shared inbox, CRM and invoicing, with cloud available for teams that would rather not run it. Free for the first three seats either way.

Telegram, LINE and WeChat webhooks are not like email: notes from wiring six channels into one queue

iMonitor Software — Wed, 28 Oct 2026 16:45:23 +0000

Email is forgiving. A webhook from a messaging platform is not. Here is what actually differs when you put Telegram, LINE, WeChat, WhatsApp and a website widget behind one inbox.

1. Each platform answers "did it arrive?" differently

Email has bounces. WhatsApp has receipts. LINE has its own delivery semantics. Telegram tells you the message was sent to the Bot API and nothing more. The website widget has no delivery state at all — a successful HTTP response is the whole story.

Modelling one status enum across all of them produces a field that means nothing. Keep the provider's native state and a small normalised enum used only to decide whether the UI may say "delivered".

2. Retries are guaranteed, ordering is not

Webhooks retry on timeout. Mobile clients queue and flush. A conversation arriving from a device that was offline will not be in timestamp order, and it will not arrive once.

Two things make this survivable: an idempotency key taken from the provider on every inbound event, and an ordering key stored alongside the message so the UI sorts on provider sequence rather than arrival time.

3. Identity is the hard part, not transport

The same person writes on WhatsApp, then emails, then opens the widget. Three identities, one human.

Resolve identity on ingest (same phone, same verified email), not on read. The cost is a merge operation when two channel identities turn out to be the same person later — which is testable — instead of reconciling three histories at query time, which is not.

4. Media is a liability, not a feature

Attachments arrive as either a URL with an expiry, a base64 blob, or a provider-hosted id that needs a second call. All three need to be mirrored into your own storage on ingest, with size limits and type checks, or your inbox breaks silently six months later when the provider rotates its CDN.

5. Rate limits shape the UI

Some platforms cap outbound messages per second per account. If the composer does not know that, an agent replying to a burst gets a silent failure. Surface the queue depth per channel, not a global spinner.

6. What we deliberately did not build

No workflow builder, no plugin marketplace. Six channels, one queue, three triage primitives (tags, priority, views), and AI drafts that live inside the conversation so a human can take over mid-thread.

The product this went into is Onsites AI — a shared inbox across website chat, email, Telegram, WhatsApp, Messenger, LINE and WeChat, with CRM and invoicing attached, free for the first three seats.

Routing seven messaging channels into one queue: what actually decides the design

iMonitor Software — Wed, 28 Oct 2026 16:08:38 +0000

Most "omnichannel support" discussions are about which channels a product supports. The harder part is the data model behind them: what a conversation is when the same person writes on WhatsApp, then emails, then opens the chat widget.

Here are the four decisions that shaped ours, and the trade-offs behind them.

1. A conversation belongs to a customer, not to a channel

The intuitive model is one table per channel: whatsapp_messages\, email_threads\, chat_sessions\. It is easy to build and painful to live with. The moment a customer switches channel, the history splits, and the agent has to remember that "the person who emailed us" is also "the WhatsApp number from yesterday".

We inverted it: a conversation is an entity with a channel-agnostic identity, and each channel is an adapter that writes into it. Identity resolution (same phone, same email) happens on ingest, not on read.

The cost is a merge step: two channel identities can turn out to be one person after the fact. That is a normal, testable operation — much cheaper than reconciling three histories at query time.

2. Delivery state is per channel, not per message

Email has SENT\, DELIVERED\, BOUNCED\. WhatsApp has its own receipt semantics, LINE another, and the web widget has none of them — the "delivery" is just a successful HTTP response.

If you model one status enum for all channels, you end up with a lowest-common-denominator field that means nothing. We keep the provider's native state alongside a small normalised enum used only for UI decisions (is it safe to show "delivered"?).

3. Out-of-order ingestion is the default, not the exception

Webhooks retry. Mobile clients queue and flush. A conversation arriving from a laptop that was offline will not be in timestamp order.

Two things made this survivable: an idempotency key from the provider on every inbound event, and an ordering key (provider message id or a monotonic sequence) stored with the message, so the UI sorts on delivery rather than on arrival.

4. AI needs to be inside the conversation, not beside it

The tempting design is a separate AI service that reads a copy of the conversation and posts a suggestion. It demos well and fails the audit: the reply lives in a log nobody reads, and a human taking over cannot see what the assistant already told the customer.

We attach generated drafts to the conversation itself. Any agent can take over mid-thread, the draft is visible in place, and billing is per action rather than per seat — so cost tracks work rather than headcount.

What we did not build

No workflow builder. Three primitives (tags, priority, views) cover triage for a team of three to ten, and every branch-based builder we have seen at this size gets abandoned in a month. No plugin marketplace either — the seven channels we support are the ones small teams actually receive messages on.

The product doing this is Onsites AI — free for the first three seats, cloud or self-hosted. If you want the operational side rather than the architecture, the small-team support desk guide covers the decisions in order.