From Skype Archives to Docker: Building a Self-Hosted Team Workspace

title: From Skype Archives to Docker: Building a Self-Hosted Team Workspace
published: true
description: How MyChat connects searchable history, calls, Kanban, file sharing, and infrastructure control inside one self-hosted workspace.

tags: selfhosted, devops, docker, productivity

A corporate messenger is easy to describe as a list of features:

• text messages;
• calls;
• file sharing;
• task management;
• mobile applications.

But teams rarely adopt communication software because they need another chat window.

They adopt it because they need to preserve years of work, find old decisions, keep conversations inside their infrastructure, and avoid splitting communication between several unrelated services.

Over the past year, we have been developing MyChat around this idea.

Instead of treating messaging, calls, files, and tasks as separate features, we tried to connect them into a continuous workflow — from migrating old conversations to deploying the server in Docker.

This is what we learned along the way.

Migration is not just about moving user accounts

When Skype was retired, many companies faced a problem that was more complicated than choosing a replacement.

Years of conversations remained inside the old platform.

These conversations often contained:

• agreements with customers;
• technical support cases;
• contact details;
• project decisions;
• links and files;
• discussions with former employees.

Starting with an empty messenger would mean losing part of the company’s working memory.

That is why we added a Skype import tool to MyChat Server.

It transfers contacts and message history into MyChat. Images, links, call information, private conversations, and group chats remain available after the migration.

New messages can then continue directly after the imported history.

The technical transfer was only one part of the problem, however. Importing thousands of messages is not especially useful when nobody can find anything inside them.

A message archive should work like a knowledge base

Corporate chat history grows quickly.

After several years, it contains much more than casual conversations. It becomes an informal knowledge base filled with solutions, instructions, decisions, and explanations.

This led us to add full-text search across private dialogues and conferences.

Users can search by words or exact phrases and filter the results by:

• sender;
• date;
• conversation;
• content type.

The search also includes a fuzzy mode for queries with minor spelling errors.

Under the hood, MyChat Server creates a separate search index using SQLite FTS. The original message database remains the source of truth, while the search index can be rebuilt independently.

This separation was important for us. Search should make the history easier to use, but it should not become a dependency that can affect message delivery or damage the original data.

Results are returned in portions, so users can begin reviewing them without waiting for the entire query to finish. New messages continue to be delivered while the server processes searches.

Once history becomes searchable, an imported archive stops being a backup that nobody opens. It becomes part of everyday work.

Data ownership also includes the right to delete data

Self-hosting is often discussed in terms of storage location.

But owning the server is not enough. Administrators also need control over the complete data lifecycle.

For some companies, keeping history indefinitely is useful. Others have internal policies that require certain conversations to be removed.

We therefore added an option to completely delete the history of a private dialogue or conference.

This is different from hiding messages in a client application. The selected history is physically removed from client devices and databases.

Because this operation cannot be undone, it is controlled through server permissions. Administrators can decide which user groups are allowed to perform it.

The server also records the action, including the user and timestamp.

This creates a balance between two requirements that may initially appear contradictory:

1. preserve valuable communication;
2. delete it completely when company policy requires it.

Both are part of data ownership.

Calls should remain connected to the conversation

Another common workflow problem appears when text communication and calls live in separate services.

A discussion starts in a chat. Someone creates a meeting in another application. Files are sent through a third service. After the call, the team returns to the original chat and tries to reconstruct what happened.

We wanted to keep this context together.

MyChat now supports audio conferences in its Windows, macOS, Linux, Android, iOS, and web clients.

A team can start a group call directly inside an existing text conference. Participants can continue sending messages, screenshots, and files while the call is active.

The interface shows:

• who started the call;
• who joined;
• whose microphone is muted;
• who is currently speaking.

After the call, MyChat adds a summary with the participants and the time each person spent in the conference.

The calls are built with WebRTC. Media streams are encrypted through DTLS-SRTP, and a TURN server can relay encrypted traffic when direct connections are unavailable.

Because MyChat is self-hosted, calls can remain inside the company’s own infrastructure. They can also work in a private network or VPN without depending on a public conferencing account.

The goal is not simply to add another call button. It is to keep the discussion, call, files, and follow-up messages in the same context.

Tasks should not disappear when someone leaves their desk

Communication software is often designed around employees sitting in front of desktop computers.

Real teams are more complicated.

Engineers may be working on-site. Warehouse employees may only have smartphones. Managers may need to review a task while travelling. Support specialists may move between different workplaces.

For this reason, we adapted the built-in MyChat Kanban board for smartphones.

From a mobile device, users can:

• open and create tasks;
• read descriptions;
• add comments;
• attach files;
• review project activity;
• update work while away from a computer.

We also added voice messages to modern MyChat clients and made it possible to attach them to Kanban tasks.

Voice is not a replacement for a clear task description. However, it can be useful when an engineer needs to explain a detail from the field or when typing a long clarification is inconvenient.

The important part is that the task remains connected to the same system as the discussion and files.

There is no need to copy information from a messenger into a separate project tracker and then explain the context again.

File sharing should preserve structure, not create chaos

Sending one document through a messenger is simple.

Sending an entire project directory is not.

Users normally have to create an archive, upload it, explain its contents, and ask the recipient to extract it. Alternatively, they send dozens of individual files and turn the conversation into a long stream of attachments.

We introduced file bundles to handle this case.

A user can select multiple files and folders, and MyChat sends them as one package while preserving the original directory structure.

This is useful for:

• application logs and screenshots;
• project documents;
• source materials;
• photo reports;
• configuration files;
• internal archives.

If the network connection is interrupted, the transfer can continue after reconnection. This matters when a package contains hundreds of files or is being transferred through an unstable connection.

We also added drag-and-drop support between MyChat and Windows Explorer or other applications.

A received image can be dragged directly into an editor. A document can be moved into a project folder. Files can also be sent to MyChat from the Windows Explorer context menu.

These are relatively small interface improvements, but they reduce the number of actions users repeat every day.

Self-hosting should fit existing infrastructure

For a long time, MyChat Server was primarily deployed in Windows environments.

However, many administrators now manage their infrastructure through Linux servers, virtual machines, containers, and automated deployment tools.

To fit this workflow better, we prepared a production-ready Docker image of MyChat Server for Linux.

Administrators can deploy the messenger in a container and manage it using familiar Linux and Docker tools.

This is important because self-hosted software should not force a company to redesign its infrastructure around one application.

The application should fit into the infrastructure that already exists.

Why these features belong together

Skype history import, full-text search, controlled deletion, audio conferences, mobile Kanban project management, file bundles, and Docker deployment may look like unrelated release notes.

For us, they solve different parts of the same problem.

A team communication platform needs to provide three things.

Continuity

Old conversations should not disappear when a company changes its communication system.

Context

Messages, files, calls, and tasks should remain connected instead of being scattered across multiple services.

Control

The company should decide where the server runs, how long information is stored, who can access it, and when it must be removed.

This is the direction in which we are developing MyChat: not simply as a messenger, but as a self-hosted workspace where communication remains searchable, manageable, and connected to daily work.

There is still a lot to improve, especially around deployment automation, integrations, search, and mobile workflows.

But connecting these parts has already changed how we think about corporate chat.

How does your team handle this today? Do you keep chat, calls, files, and tasks in one platform, or combine several specialized tools?