## Key Takeaways

- **The URL is part of the deliverable.** A client who gets a link on a domain they do not recognize forwards it to their security team before they read the numbers.
- **Viktor Spaces can now run on a domain you own.** Any workspace admin points a domain at a Space from its Settings tab, and Viktor walks through the DNS records and provisions the certificate, per the [Viktor changelog of August 11, 2026](https://viktor.com/changelog).
- **Access rules carry over.** Whatever gate the Space already had stays in place on the new hostname, so moving the address is not a way to accidentally open something up.
- **Published pages get one hostname.** Ask for a domain on your pages and it serves the whole namespace, with per-page access preserved.
- **Use it where the audience is external.** Client reporting, partner portals, candidate-facing pages. For a dashboard three people on your ops team read every morning, the default subdomain is fine.

An agency ops lead asked Viktor for a live client dashboard: spend, leads, cost per lead, refreshed every morning from Google Ads and HubSpot. Viktor built it and shipped a working URL the same afternoon. She sent it to the client at 4 PM. At 4:20 the client's IT manager replied to the thread asking what viktor.space was, whether it was approved, and whether the numbers on it were the ones in the contract.

Nothing was wrong with the dashboard. The address on it was doing the talking.

That gap is now closable. Since August 11, 2026, a workspace admin can point a domain they own at a Space, and the same treatment applies to published pages. The dashboard stops looking like a third-party tool and starts looking like the reporting you promised.

## What actually changes when a Space runs on your own domain?

The content, the access rules, and the refresh schedule stay exactly as they were. What changes is who has to think about the link.

On a default subdomain, every new viewer runs a small trust check in their head. On `reporting.youragency.com`, nobody runs it. That is the whole benefit, and it is bigger than it sounds when the viewer is a client, a partner, or a candidate you have never met.

| Where the work lives | Who is comfortable opening it | Best for |
| --- | --- | --- |
| Named Space subdomain (`yourproject.viktor.space`) | Your team, and anyone you have already briefed | Internal dashboards, weekly ops views, quick prototypes |
| A domain you own (`reporting.youragency.com`) | Clients, partners, candidates, anyone cold | Client reporting, partner portals, anything that goes out under your name |
| A page your engineers build and host | Everyone, eventually | Product surfaces that need to live in your codebase forever |

The third row is the one worth staring at. Most internal tools never get built because they would have to enter that row: a ticket, a sprint, a deploy pipeline, an owner. Row two gets you the trust of row three without borrowing an engineer.

![Comparison of a default Space subdomain, your own domain, and an engineering build](/images/blog/how-to-put-your-ai-employees-work-on-your-own-domain/who-opens-the-link.webp)

### Where this fits with what you already ship

If you have not built a Space yet, start with [how your AI employee builds dashboards and internal tools](https://viktor.com/blog/how-your-ai-employee-builds-dashboards-and-internal-tools) and come back. The domain step is the last 10 minutes of a job, not the first.

## How do you point a domain at a Space?

Four steps, and an admin does all of them.

1. Open the Space and go to its Settings tab. Any workspace admin can do this, not only the person who created the Space.
2. Add the domain or subdomain you want to use. Pick a subdomain you control, like `reporting.youragency.com`, rather than your apex domain.
3. Add the DNS records Viktor gives you at your registrar. This is the only step that happens outside the conversation, and it is the one your IT person will want to see.
4. Wait for the certificate. Viktor provisions it, so there is no certificate request to file.

![The four steps from a Space to your own hostname](/images/blog/how-to-put-your-ai-employees-work-on-your-own-domain/four-steps.webp)

Ask for it the same way you ask for anything else:

```prompt
@Viktor put the client spend dashboard on reporting.ouragency.com and tell me exactly which DNS records to add at Cloudflare
```

When the records are in and the certificate is issued, the old address keeps working and the new one starts working. Send the new one.

## Do the access rules follow the domain?

Yes, and this is the part worth saying out loud to whoever approves it: whatever access policy the Space already had is carried over to the new hostname. A login-gated Space stays login-gated. An open-link Space stays open.

So the sequence matters. Decide the gate first, move the domain second. If you are not sure what the gate should be, [how to control what your AI employee can access](https://viktor.com/blog/how-to-control-what-your-ai-employee-can-access) covers the same decision on the data side.

A short version for the three cases we see most:

- **Client reporting.** Login gate, restricted to the client's email domain. They see their account, nobody else's.
- **Partner or candidate pages.** Open link on your domain. There is nothing confidential on it and you want zero friction.
- **Internal ops views with revenue in them.** Login gate, your domain only if leadership forwards it around. Otherwise leave it on the default subdomain and save yourself the DNS conversation.

## What about published pages, not Spaces?

Pages get the same treatment with one difference: you ask once, and a single hostname serves your whole page namespace. Per-page access carries over, so a page that was restricted stays restricted after the move.

That makes it worth thinking about naming before you have twenty pages. `docs.yourcompany.com` for client-facing documentation and a separate internal path for the rest is easier to explain later than one hostname that grew whatever landed on it.

```prompt
@Viktor serve our published pages on help.ourcompany.com, keep the internal rate-card page restricted to our workspace, and list every page that will be publicly reachable after the switch
```

Ask for that list. It takes Viktor a minute and it is the single check that stops an internal page from riding along to a public hostname.

## Who should skip this?

Teams whose Spaces have exactly one audience: themselves.

If the only people opening the link are already in your Slack workspace, a named subdomain is doing its job and a custom domain adds a DNS record you now have to remember to keep. We run plenty of internal views on default subdomains and have never had a reason to move them.

The signal to move is external eyeballs. The moment you paste the URL into an email to somebody outside your company, the address becomes part of how the work is judged.

## A five-minute checklist before you move a Space

- Confirm who the audience is, and that it includes people outside your workspace.
- Set the access gate you want first, and check it by opening the link in a private window.
- Pick a subdomain you control, not your apex domain, so your marketing site is never in the blast radius.
- Have the DNS records added by whoever owns the registrar, in one sitting.
- After the certificate is live, ask Viktor to list every page reachable on the new hostname and read that list.
- Update the link everywhere you already sent the old one, including your recurring reports. [Recurring tasks your AI coworker should own](https://viktor.com/blog/recurring-tasks-your-ai-coworker-should-own) is a good prompt for finding those.

## Frequently Asked Questions

### Can a Viktor Space run on my own domain?

Yes. As of August 11, 2026, a workspace admin can point a domain they own at a Space from the Space's Settings tab. Viktor supplies the DNS records to add and provisions the certificate. Older guidance saying Spaces are limited to named viktor.space subdomains is out of date.

### Do I need an engineer to set it up?

You need whoever can add DNS records at your registrar, which in most 10 to 50 person companies is an ops lead with the Cloudflare or GoDaddy login. Nothing has to be deployed, built, or reviewed.

### Does moving to my own domain change who can see the Space?

No. The access policy the Space already had is carried over to the new hostname. If it was gated, it stays gated. Set the gate you want before you move, and verify it in a private browser window afterwards.

### Can I use my main website domain?

Use a subdomain of it, like `reporting.yourcompany.com`. Pointing your apex domain at anything other than your website is a change your marketing team will notice, and a subdomain gives you the same recognition without touching the site.

### What happens to the old viktor.space URL?

It keeps working, which is useful during the switchover while people still have the old link in their inbox. Send the new one going forward and update it in any recurring report that includes it.

### Does this work for published pages too?

Yes. Ask Viktor to add a domain for your pages and one hostname serves your whole page namespace, with per-page access carried over. Ask for the list of publicly reachable pages after the switch before you announce the new address.

## Related reading

- [How to share your AI employee's work outside your team](https://viktor.com/blog/how-to-share-your-ai-employees-work-outside-your-team)
- [How your AI employee builds dashboards and internal tools](https://viktor.com/blog/how-your-ai-employee-builds-dashboards-and-internal-tools)
- [Ship internal tools without engineers](https://viktor.com/blog/ship-internal-tools-without-engineers)
- [How to control what your AI employee can access](https://viktor.com/blog/how-to-control-what-your-ai-employee-can-access)

---

**Viktor is an AI employee that lives in Slack, connects to 3,200+ integrations, and does real work for your team.** [Add Viktor to your workspace -- free to start →](https://viktor.com/?utm_source=blog&utm_medium=cta&utm_campaign=how-to-put-your-ai-employees-work-on-your-own-domain)