Cloud and on-premises

The API, the messages and the session model are the same everywhere. What differs is how you reach the server and how users authenticate.

	M-Files Cloud	On-premises
Address	The vault host on port 443, for example `contoso.cloudvault.m-files.com:443`	The server's host name and the gRPC port, 7766 by default
Transport	TLS, publicly trusted certificate	Plain HTTP/2 by default; TLS when the administrator enables it, with the certificate they install
Front end	A front end between client and server; several server instances can serve one vault	The client talks to M-Files Server directly, or to the M-Files reverse proxy (Traefik) where one is deployed
Stickiness	The front end sets the cookie `mfilesmsm`; send it back on later calls	None
Typical authentication	Single sign-on through M-Files Login Service (plugin `MFLoginService.Default`), which M-Files Cloud vaults are moving to; otherwise through the vault's identity provider. Both are `AUTH_DATA_TYPE_PLUGIN` with a token	M-Files user name and password, Windows authentication, or single sign-on where configured
Login accounts	Vault-level login accounts (`vault_login_accounts` capability)	Server-level login accounts unless configured otherwise
Server version	Chosen by M-Files; check it with `QueryVersion`	Whatever version the customer runs
mf-http-grpc gateway	Same host, port 443, paths `/grpc/v1/...`	Port 7767 by default

Practical consequences

Find the authentication method first. Call GetAuthenticationConfiguration anonymously with host_name set to the host you connect to. On an M-Files Cloud vault it returns AUTH_METHOD_PLUGIN and the OAuth plugin with its identity provider settings and the vault GUID. When the plugin is MFLoginService.Default, sign in through M-Files Login Service: see M-Files Login Service. Other plugins: see Single sign-on.
Keep cookies on M-Files Cloud. Store set-cookie values from response headers and send them in a cookie header on every later call of the session. See Call metadata.
Trust the right certificate on-premises. A server with a private or self-signed certificate needs its CA in your client; a server without TLS needs an insecure channel. See Connecting.
Do not hard-code capabilities. Cloud and on-premises servers run different versions. Use QueryVersion and GetServerCapabilities; see Versions and compatibility.

Both deployments answer QueryVersion without a session or any metadata:

Target	Channel	Example answer
`contoso.cloudvault.m-files.com:443`	TLS, default trust	`server_version` 7318389121155072 (26.9.16357.0)
`mfserver.example.local:7766`	Insecure (or TLS with your CA)	`server_version` 7318397729964032 (26.11.16645.0)

The Connecting page explains how to decode the version and what a failure means.