Server types and roles: file, web, database, directory and application
In short: A server is any computer that provides a service to other machines. The role describes that service: storing files, serving web pages, holding data, checking identities or running business logic. Real systems combine several roles, and good design decides which ones share a machine and which stay apart.
What makes something a server
A server is defined by what it does, not what it looks like. If a computer listens for requests from clients and answers them, it is acting as a server. A laptop running a small web service is technically a server; so is a rack of hardware in a data centre. The word role names the service being offered. One physical or virtual machine can hold one role or several.
The main roles
| Role | What it does | Common examples | Typical ports |
|---|---|---|---|
| File server | Stores shared files and controls who can open them | Windows file shares (SMB), Samba, NFS on Linux | 445 (SMB), 2049 (NFS) |
| Web server | Answers HTTP and HTTPS requests with pages or API responses | Nginx, Apache HTTP Server, Microsoft IIS | 80, 443 |
| Database server | Stores structured data and answers queries | PostgreSQL, MySQL, Microsoft SQL Server | 5432, 3306, 1433 |
| Directory server | Holds users, groups and computers and checks who they are | Active Directory Domain Services, OpenLDAP | 389 (LDAP), 636 (LDAPS), 88 (Kerberos) |
| Application server | Runs the business logic between the web front end and the data | Java, .NET or Node.js runtimes | Varies, often 8080 or 8443 |
| Infrastructure server | Provides the basic network services everything else relies on | DNS, DHCP, NTP, print, backup | 53, 67/68, 123 |
Use the port lookup tool to check other well-known ports. Notice that the infrastructure roles are easy to forget, yet if DNS fails, almost every other service appears broken.
How roles work together
Most business applications follow a three-tier pattern. The web tier faces users, the application tier applies rules (for example, "only managers can approve orders"), and the data tier stores records. A directory server sits alongside to confirm who the user is. Splitting tiers lets you scale each one separately and put firewalls between them, so a compromised web server cannot talk straight to the database.
Combine or separate?
In a small office, one server might run file sharing, DHCP and DNS together. That is cheap but creates a single point of failure. As an organisation grows, roles move onto separate virtual machines. Consider these points:
- Security: never put a public web server on the same machine as a domain controller. A breach of one would expose both.
- Performance: databases want lots of memory and fast disks; file servers want capacity. Mixing them causes contention.
- Availability: critical roles such as directory and DNS should run on at least two servers.
- Patching: separate roles can be updated and restarted without taking everything down.
Tip: when you document a network, list every server with its roles, owner, operating system and the ports it should expose. This one table makes audits, firewall reviews and troubleshooting far easier.
A common mistake is the "do everything" server that nobody dares reboot. If you inherit one, plan to split its roles gradually, starting with the riskiest.
Practice
A user can reach the intranet by IP address but not by name. Which server role should you check first?
Why is it poor practice to run a public website on a domain controller?
In a three-tier design, which tier should be able to talk to the database?
Key takeaways
- A server is defined by the service (role) it provides.
- Core roles: file, web, database, directory, application and infrastructure.
- Three-tier designs split web, application and data so each can scale and be firewalled.
- Separate high-risk and critical roles; run directory and DNS on at least two servers.
- Keep an inventory of each server, its roles and expected ports.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.