The same deploy, asked in one sentence

Outcome

By the end of this lesson, you will be able to ship a deploy through an assistant, explain what the three write tiers admit, and predict which of your requests will be refused before you make them.

1. Concept

The same four objects, the same order, one sentence instead of four forms.

What makes that safe is not the assistant. It is the server, which checks three things on every write and refuses if any one of them is missing:

1. THE ORG'S WRITE ACCESS SETTING admits this class of change
2. YOUR ROLE permits the underlying action
3. YOUR TOKEN carries the matching write capability

All three, every call. A refusal is permanent rather than a retry: nothing about asking again changes any of the three.

The three write tiers

TIER 1  METADATA ONLY        renaming a project or an environment.
                             Changes ZopNight's own records. No cloud
                             state, no cost.

TIER 2  REVERSIBLE CHANGES   creating a project, an environment, a
                             service; shipping a deploy; rolling back;
                             setting environment variables. Bounded
                             blast radius, may affect cost.

TIER 3  IRREVERSIBLE         registering or removing infrastructure,
                             starting a database migration, starting
                             or stopping a cloud resource directly
                             (start_resource, stop_resource). No undo,
                             or it costs money the moment it runs.

Everything in this part sits in tier 2: deploy, redeploy and rollback. Reading logs is a read. That is a deliberate choice about what a capstone should teach you to trust an assistant with.

This is the shipping half of the capstone. The service runs on ZopCloud’s shared pool, not in your cloud account, so ZopNight does not discover it and you will not find it in ZopNight’s resource list. You operate it through these deploy tools instead.

What you will never get back

One rule worth memorising, because people test it and are surprised:

NO TOOL RETURNS AN ENVIRONMENT VARIABLE'S VALUE.
Keys, yes. Values, never, at any tier, for any role.

Reading a secret back is a human action in the console, on purpose.

2. Demo

YOU    "Create a project called university-capstone with a dev
        environment, deploy ghcr.io/me/hello-api:v1 on port 8080,
        expose it, and give me the URL."

ASSISTANT
  creates the project              tier 2
  creates the environment          tier 2
  creates the service and deploys  tier 2
  waits for the deploy to finish
  returns https://hello-api-<id>.<your-zopcloud-domain>

YOU    "Now roll it back."
ASSISTANT
  rolls back to the previous deploy  tier 2

YOU    "Remove the cluster from the platform."
ASSISTANT
  refused: tier 3 is not enabled for this organisation

The last exchange is the lesson. The refusal came from the server, not from the assistant’s judgement.

3. Hands-on (6 min)

1. Connect your assistant to ZopCloud if you have not already.
   Setup for every supported client is covered later in the course.
2. Ask it what it is allowed to do in this organisation.
3. Ask it to deploy a second service into the same environment,
   in one sentence, the way you would tell a colleague.
4. Ask for the URL and open it.
5. Ask it to roll the service back, then to redeploy it.
6. Ask for the service's logs and its last build log.
7. Ask for something at tier 3 and read the refusal carefully.

Do it through MCP. The same task you just did in the console, asked in one sentence.

BEFORE  A ZopCloud account, the project and environment from L3, and an
        image you can pull.
ASK     "Deploy hello-api-2 from this image into university-capstone dev, expose it, and give me the URL."
CHECK   the URL answers, and the service shows one deploy in its history.

Tools behind it: create_project (write, tier 2, reversible), create_environment (write, tier 2, reversible), deploy_service (write, tier 2, reversible), redeploy_service (write, tier 2, reversible), rollback_service (write, tier 2, reversible), set_service_expose (write, tier 2, reversible), wait_for_deploy (read, Ship), get_service_url (read, Ship), get_service_logs (read, Ship), get_build_logs (read, Ship). Connection details are in the MCP integration docs.

4. Knowledge check

Q1

Your assistant refuses to ship a deploy. Your role is Admin and the organisation has write access turned on. The remaining explanation:

A. The image is not pullable
B. The token you connected with does not carry the write capability
C. Deploys are tier 3
D. The environment is in a different project

Q2

Which of these is tier 3?

A. Creating an environment
B. Setting environment variables on a service
C. Removing a cluster from the platform
D. Rolling a service back

Q3

You ask your assistant to read back the database password it just set on your service. It declines. Why?

A. The value is encrypted and it lacks the key
B. Reading secrets requires tier 3
C. It needs a fresh token first
D. No tool returns an environment variable’s value, at any tier, for any role

5. Apply

Before you let an assistant near a real environment, ask it what it is allowed to do and read the answer. It costs one question and it tells you which of the three checks is going to stop you.

KEEP
  the deploy you shipped through the assistant
  the refusal message from the tier 3 request

The refusal is worth keeping because it is the clearest description of your organisation’s current write posture that you will find anywhere.

Related lessons

• L3: Deploy a service on ZopCloud
• L5: Evidence, and what certification checks
• T6.M6.5.L2: When you need writes

Glossary terms touched

MCP · PAT · Deployment · MCP configuration