# On the company's server, behind the VPN, or in the company's cloud

> A solution does not have to live on a laptop or in someone else's account. The company's own server, the company VPN, or the company's own cloud is enough.

> Source: https://www.mainpath.ai/en/blog/own-servers/

An internal application needs to run on an existing server. Another project needs access to the company network, while a third already uses a cloud account. MainPath offers different hosting paths for these situations. The starting points are where the application should run and how MainPath can reach that environment.

## Use a server you already have

{{< picture src="images/home/features/server.png" alt="Server" >}}

You can connect an existing Linux server over SSH. MainPath needs a reachable host and a user with the required permissions. Setup and the first deployment also cover Docker, certificate configuration, and the firewall.

The guide to [your own server](/en/docs/own-server/) explains credentials, setup, and assigning the server to a project. The application's domain records must also point to the server so requests can reach it.

## Reach internal servers through a VPN

{{< picture src="images/home/features/server-setups/firewall.png" alt="Firewall" >}}

If the server is only reachable internally, MainPath joins the existing network through WireGuard or OpenVPN. The application stays on the server in your network. The tunnel provides access for setup and deployments.

This connection does not automatically determine who can open the application in a browser. If you serve a public website, HTTP and HTTPS must remain reachable accordingly. The [network tunnels guide](/en/docs/network-tunnels/) explains setup and assigning a tunnel to a server.

## Run Kubernetes in the company's cloud account

{{< picture src="images/home/features/server-cloud.png" alt="Cloud with servers" >}}

For Kubernetes, MainPath uses a company account on AWS, Azure, Google Cloud, or Open Telekom Cloud. You can create a cluster there. You can also import an existing cluster through its kubeconfig.

Creating and importing have different requirements. An imported cluster can host applications, but cannot create a managed database in the cloud account. The [Kubernetes guide](/en/docs/kubernetes-integration/) covers both paths and selecting a cluster in your project.

## Agree on the setup before deployment

Establish who owns the server or cloud account, which access MainPath will use, and how users should reach the application. Those decisions determine whether you prepare direct SSH access, a tunnel into the internal network, or a Kubernetes cluster.

For a broader discussion with your team, see [MainPath for companies](/en/enterprise/).