Skip to content
Overview · Concept Beginner

When Sluicio is run for you

What is different when a provider runs your Sluicio instance instead of you running it yourself - claiming the instance with your setup link, what your provider owns, and what stays yours.

SLSluicio team 4 min read Updated Sep 2026

Sluicio comes in two shapes. Either you run it yourself, on your own infrastructure, which is what the rest of these docs assume. Or somebody runs an instance for you, and hands you the address.

This page is the second case. Your data, your orgs and your alerts are yours either way. What changes is the plumbing underneath: the mail server, how long telemetry is kept, the addresses the instance answers on. Those belong to whoever runs the instance, and they are read-only for you.

If you are not sure which you have, open Settings. On an instance run for you, there is no operator area, and the panels described below say where their values come from.

An instance that is run for you arrives with no password set. You get a setup link, you open it once, and the account you create with it becomes the first admin of the instance.

Two things worth knowing about that link:

  • Treat it as a password. Whoever opens it first becomes the admin. Don’t forward it, don’t paste it into a group chat, and don’t put it in a ticket.
  • It may expire. If the link no longer works, ask for a new one. A new setup link is a new link; the old one stops working.

Once the instance is claimed, the link is spent. Everyone else joins the normal way: you invite them, or they sign in through your identity provider if you have SSO.

These are properties of the instance rather than of your organization, so they are set by whoever runs it. You can see them, and Sluicio will tell you it is not your setting rather than failing quietly when you try to change one.

  • Sending email. There is no SMTP server for you to configure. Sluicio shows whether sending is working and nothing else, because the mail transport is not yours.
  • How long telemetry is kept. Retention is shown read-only, for traces, logs, metrics and audit history. How long your data is kept is worth knowing even when you cannot change it, so the numbers stay visible.
  • The addresses. Where you send telemetry, and the address the app is reached on.
  • The environment label, if the instance shows one in the top bar.
  • Announcements and other instance-wide notices.
  • Enterprise features. There is no license key for you to enter. Whether the Enterprise features are available is part of what you were given; see Identity & SSO for the free-core / Enterprise split.

If you need one of these changed, ask whoever runs the instance for you.

Everything about how you use Sluicio:

  • Your organizations, teams and users, and who can see and manage what. Roles and access works exactly as documented.
  • Requiring two-factor for your own people. Whether your users must use 2FA is your decision, not your provider’s, so it sits with an org admin.
  • Integrations, systems and system types, including your own custom types.
  • Alert rules, profiles and maintenance windows, as in Alerting.
  • Who gets told. Notification channels are yours: you pick the recipients of an email channel, the Slack workspace, the webhook. Email channels choose recipients and nothing else, since the server behind them is the instance’s.
  • Ingest keys and API tokens, dashboards, and anything you share.