Introduction to MikroTik Hotspot User Management
If you run a captive portal for guests, you already know the real job is not getting people online. It is deciding who gets online, for how long, and how much of your connection each person can use. That is what MikroTik hotspot user management does. It gives you a way to control who can use the portal, how long their access lasts, and how their traffic is handled.
When you manage MikroTik hotspot users well, your network stays fair and predictable. When you skip it, one heavy user or one shared password can quietly affect everyone else. Creating users, assigning profiles, and monitoring active sessions cover most of the work.
This guide explains how MikroTik hotspot user management works from the ground up, in plain language. You will see how a login becomes a session, where user records live, how profiles carry shared rules, and how rate limits, timeouts, and sharing settings shape access. We finish with monitoring and a short FAQ. Everything here stays at the concept level, so you can apply it whatever your setup looks like.
How the Hotspot Captive Portal Handles User Sessions
A captive portal is the page a guest meets before they can use the network. Its job is to tie together the connection a device makes, the authentication a person completes, and the session that follows. If you want related reading on how captive portals work in general, that article makes a good companion to this one.
The most useful way to think about a session is as a managed state. It does not exist while a guest is only connected. It starts once authentication succeeds, and it ends through a timeout being reached, a limit being used up, or an operator ending it by hand. Every setting you meet later in this guide is a way of shaping that state.
Login Flow from Connection to Authentication
The MikroTik captive portal login flow follows a simple order. First, a guest connects a device to your network. Next, the hotspot recognizes that the device has not yet been approved and presents the login portal. The guest then submits their credentials. The router checks those credentials against its source of user records, and if they match, authentication succeeds.
Success is the moment that matters. It creates a session context, which is the record that says this identity is now authorized to use the network under a defined set of rules. Until that moment the device stays in a restricted state. After it, the guest gets access that your profile and limits describe.
Relationship Between Hosts, Users and Active Sessions
A few terms show up constantly during monitoring, and mixing them up causes real confusion. Here is MikroTik hotspot hosts vs users in plain terms.
A host is a connected device that the hotspot can see, either before login or without ever logging in. A user is an authenticated identity, the account a person signs in with. An active session is the current authorized access state that links a device to an identity after a successful login.
So a host can exist with no user attached. A user only becomes visible as an active session once someone signs in. Having MikroTik hotspot user vs host explained this way helps you read what you see on screen. A device listed without a session is simply connected but not yet approved. A session means someone passed authentication and is now under your rules.
Hotspot Server Setup and Where Users Are Stored
MikroTik hotspot server setup is about turning the hotspot function on and shaping how it behaves. It is separate from the question of where user records live. The server decides how the portal runs and when it asks for a login. The user storage decides whether a given set of credentials is valid. Keeping those ideas apart makes everything else easier to reason about.
If you want related reading on how to connect MikroTik router equipment to other systems, that page is worth a look after this section. For now we stay inside MikroTik and look at the server side first, then the storage side.
Hotspot Server Instances and Server Profiles
A hotspot server instance is the hotspot function running on a defined interface area of your router. It is the thing that actually watches for new devices and sends them to the portal.
A server profile holds the behavior settings tied to that instance. Think of the MikroTik hotspot server profile as a grouping of portal and session behavior that applies around your users. It shapes how the login experience works and how sessions are treated at the server level, while user profiles, covered later, carry the rules for individual accounts. If you can picture the instance as the doorway and the server profile as the house rules posted at that doorway, you have the right idea.
Local Users Compared with External Authentication Sources
Local users are accounts stored on the router itself. When a guest logs in, the router checks the submitted credentials against its own list. External authentication sources are outside systems the router consults to approve a login instead.
The choice changes where credentials are checked, and it can change who maintains the user records. It does not change the management ideas in this guide. Profiles, limits, timeouts, sharing rules, and monitoring all still apply to the sessions that result. A small operator with a modest guest list often finds local users simplest. A larger operation may prefer an outside source so records are kept in one place.
Creating and Organizing Individual Hotspot Users
Here is how to create hotspot users in MikroTik, at the level of purpose rather than clicks. A hotspot user is one account with one set of login credentials, tied to the rules you want that person to follow. Creating users is practical guest control: it lets you decide who gets in and what each person is allowed to do once they are in.
Organization matters as much as creation. A long, unsorted list of accounts gets hard to manage quickly, so plan how you will group MikroTik hotspot users before you add many of them.
Required User Fields and Credentials
At the simplest level, every user needs an identity and a secret. The identity is the name the guest types to say who they are. The secret is what proves it. Together these are the user credentials the portal checks at login.
Make each identity clear and unique. A unique identity means each session traces back to one account, which gives you accountability when you review activity or answer a support question. It also keeps session control clean. If different people share an identity by accident, you cannot tell their activity apart, and you cannot end one person’s session without affecting the other’s expectations.
Grouping Users by Profile and Comment
A pair of tools does most of the organizing work. Profile assignment is how shared rules reach many users at once. Instead of setting limits on every account, you assign each account to a profile and let the profile carry the rules. A comment is a plain label you attach to a user so you can sort, search, and recognize accounts later.
Comment grouping works best when your labels follow a pattern. You might label accounts by access type, such as short visits versus longer stays. You might label them by a location label, such as a front desk area or a meeting room. You might note which batch an account belongs to so cleanup is easy. The label has no effect on access by itself. Its value is that you can find the right accounts in seconds when something needs attention.
Understanding Hotspot User Profiles
If you want to know how to use user profile in MikroTik hotspot, start with the main idea: a profile is the central method for applying shared access rules. A MikroTik hotspot user profile is a reusable set of controls that you assign to users. Write the rules once, assign them to every matching account, and each of those users follows the same rules.
This is what keeps a growing guest list manageable. Without profiles, every change means editing every account. With profiles, one change reaches everyone assigned to the profile.
Default Profile Compared with Custom Profiles
The default profile is the starting set of rules. It applies to a user unless you assign something else. It works fine when all your guests need the same experience.
Custom profiles are separate sets that you create for different access needs. Separation helps when guests truly need different treatment, for example when one group gets lighter access and another gets more room, or when some accounts are meant for planned sharing and others are not. Create a custom profile when you notice yourself wanting to treat one group differently. Keep the number of profiles small enough that you can remember what each one is for.
Profile Settings That Apply to Assigned Users
Profile settings fall into a few families. Traffic controls shape how much bandwidth a user can take. Time controls set how long sessions and usage can last. Session sharing behavior decides whether the same credentials can be active more than once at the same moment.
The key point is that a change to a profile affects every user assigned to it. That is powerful and worth respecting. Before you edit a profile, think about who is assigned to it. Consistent assignment keeps management simple, because you always know which rules a given account follows just by knowing its profile.
Rate Limits and Traffic Controls for Users
Rate control is how you keep one guest from crowding out the rest. A MikroTik hotspot rate limit is a ceiling on the traffic a user can generate, applied through the profile the user is assigned to. Because the control lives in the profile, every user in a group is treated the same way, which supports fair use and steadier service for everyone on the network.
For related reading on router enforced speed limits, see that article. Below we keep to the generic concepts: separate limits for each direction, then burst and priority.
Download and Upload Limits by Profile
If you are wondering how to set rate limits for MikroTik hotspot users, the answer starts with the profile. You set a download limit and an upload limit as part of the profile, and every assigned user inherits them.
Download and upload are separate directions of traffic. Download is data coming to the guest, and upload is data leaving the guest. Each limit acts as a ceiling that shapes the user’s traffic in that direction. Treating them separately lets you match limits to how your guests actually use the network, since most guest activity leans more heavily one way than the other. You do not need exact figures to understand the concept. You need to know that the ceiling exists, that it lives in the profile, and that it applies to every user assigned there.
Burst Settings and Priority Handling
MikroTik hotspot burst settings add temporary flexibility around the base limit. Burst lets a user exceed the normal ceiling for a short window, which can make pages and small transfers feel more responsive, while the base limit still governs the longer run. Think of it as a little extra room that does not change the overall rule.
Priority handling is about relative treatment. When many users compete for the same connection, priority describes which traffic is handled ahead of other traffic. It matters mainly during contention, when demand is higher than what the connection can comfortably carry. Neither burst nor priority is a promise about how any connection will perform. They are tools that shape how your rules play out when things get busy.
Session Timeouts, Idle Timeouts and Uptime Limits
Rate limits control how much traffic a guest uses. Time and usage boundaries control how long and how far that access can go. These are the core session controls, and they separate into distinct ideas: interruption, inactivity, and cumulative or volume boundaries.
Understanding which one you are dealing with makes support conversations much easier. A guest who says they were kicked off might have hit a total length bound, gone inactive, or used up an allowance. Each has a different cause and a different fix. If you want related reading on how a session expiry system fits into a wider setup, that page covers the topic from another angle.
Session Timeout and Session Interruption Behavior
MikroTik hotspot session timeout is a bound on how long a single session can last. When the bound is reached, the session ends. That ending is the session interruption: the guest loses authorized access and returns to an unauthenticated state.
For the operator, the expectation is straightforward. The session ends because the profile said it would, not because something broke. For the guest, the expectation is that they will see the portal again and need to log in, subject to whatever your rules allow. Telling guests this in advance saves support effort and avoids the feeling that the network is unreliable.
Idle Timeout and Keepalive Timeout
MikroTik hotspot idle timeout deals with inactivity. If a guest stops using the connection, the idle timeout ends the session after the connection has been quiet for the allowed period. This frees up the session and keeps stale logins from hanging around.
That is the heart of MikroTik hotspot session timeout vs idle timeout. Session timeout limits the total length of a session no matter how busy the guest is. Idle timeout watches only for inactivity and ends the session when activity stops.
Keepalive timeout sits beside these. Keepalive is the concept the hotspot uses to check whether a session is still present, meaning whether the guest’s device is still there and responding. When a device disappears without logging out, keepalive helps the router notice and clean the session up.
Uptime Limits and Data Transfer Limits
Here is MikroTik hotspot uptime limit and data limit explained in plain terms. An uptime limit is the cumulative active use a user is allowed. It adds up the time a user spends connected across sessions, so it works as an overall allowance rather than a limit on one visit. A data transfer limit is the volume of traffic a user is allowed. It counts what the user moves, not how long they stay.
The difference is worth remembering. A guest could stay connected for a long time while moving little data, or move a large amount of data in a short stay. Either type of bound can end or restrict continued access, depending on how you design the profile. Pick the one that matches what you actually want to protect: connection availability or traffic volume.
Managing Shared Users and Concurrent Sessions
Sharing is a policy choice. Some operators want every credential tied to one person on one device. Others want a family or a small group to use the same account. The settings that control this let you choose, and the right answer depends on how much control you want against how much convenience you want to give guests.
How Shared User Counts Control Simultaneous Logins
Here is how shared users work in MikroTik hotspot. The shared user count sets how many simultaneous logins are allowed for the same credentials. MikroTik shared users is the policy that sets that allowance.
When the allowance permits more than a single login, several devices can sign in with the same credentials at once. Each of those logins becomes its own active session, which is what we mean by concurrent sessions. When the allowance is reached, further login attempts with those credentials are refused until a session ends. The count is a clean way to decide how far one set of credentials can stretch.
Common Patterns for Single Device and Shared Accounts
The simplest pattern is one credential for one active session. It gives you tight control and clear accountability, because each session maps to one account and one device. The tradeoff is convenience. A guest with a phone and a laptop may find it limiting.
The other pattern is one credential intended for planned sharing, such as a group travelling together or a household. It is friendlier for guests and cuts down on account requests. The tradeoff is accountability, because you cannot easily tell who among the sharers did what. It also gives you less control over how much traffic one account generates in total.
Neither pattern is right for everyone. Choose based on who your guests are, how much you need to trace activity, and how much support effort you want to carry. You can also mix them by using separate profiles for each pattern.
Monitoring Active Users and Ending Sessions
Setting rules is half the work. The other half is checking that they behave as you expect. Routine review of MikroTik hotspot active sessions supports helping guests who report problems, keeping use fair across the network, and cleaning up sessions that should no longer exist.
Monitoring does not mean watching constantly. View the status when you need it, and act only when there is a reason to. If you want related reading on how to monitor active hotspot users, that article is a useful follow-up to this section.
Viewing Active Sessions and Traffic Status
To see how to view active hotspot users in MikroTik at the concept level, think of it as asking one question: who is authorized right now, and how do their sessions look? The active sessions view lists the identities currently signed in and shows details about each session.
Traffic status adds the picture of how much each session is using. Reading it tells you who is active, how long a session has been running, and whether any single user stands out. That helps you answer a support question, spot an account that is being used in an unexpected way, or confirm that a profile is behaving as designed. The value is in the information, not in the exact steps to reach it.
Manual Disconnection and Session Cleanup
Sometimes a session needs to end before any bound would end it. Here is how to disconnect active hotspot users in MikroTik at the concept level. Manual disconnection ends a selected session on demand. The user returns to an unauthenticated state, and the session leaves your list.
Session cleanup is the result. After a disconnection, the active list is tidy again, with only sessions that should still exist. Use manual disconnection carefully. Good reasons include a support request, a stuck session, or a policy need. Because it ends access immediately, avoid doing it casually. A guest who is cut off without warning will reasonably wonder what went wrong, so be ready to explain.
FAQ
What is the difference between a hotspot user and a hotspot host?
A hotspot user is an authenticated identity, the account someone signs in with. A hotspot host is a connected device the hotspot can see, whether or not anyone has logged in on it. A host can exist without a user. A session appears when a user authenticates from a host, linking the identity to the device.
What is a hotspot user profile used for?
A hotspot user profile is a reusable set of access rules assigned to users. It carries shared controls such as traffic limits, time limits, and sharing behavior, so you write the rules once and every assigned user follows them. Changing the profile changes the rules for everyone assigned to it.
How do rate limits apply to hotspot users?
Rate limits come from the profile a user is assigned to. The profile sets a download limit and an upload limit as separate ceilings on traffic. Burst settings give temporary flexibility around those ceilings, and priority handling decides how traffic is treated relative to other traffic when the connection is busy.
What happens when session timeout or idle timeout is reached?
When the session timeout is reached, the session ends because its total allowed length is used up, no matter how active the guest was. When the idle timeout is reached, the session ends because the connection went inactive. In both cases the guest loses authorized access and returns to the login portal.
How does the shared users setting affect logins?
The shared users setting controls how many simultaneous logins are allowed for the same credentials. A low allowance keeps each credential tied to a single active session. A higher allowance lets several devices sign in with the same account, with each login counted as its own session.
Where can active hotspot sessions be viewed and disconnected?
Active sessions are viewed in the hotspot’s active session view, which shows who is currently authorized and how their traffic looks. From that same view, an operator can end a selected session by manual disconnection. The user returns to an unauthenticated state and the session list is cleaned up.