What changes when this goes live
The same repository behaves differently on your machine and on Webslice. These are the settings that differ, and what each one does in production.
Nothing about the code changes when you deploy. The environment around it does.
Where the settings come from
Locally you get .env, which composer setup copies from .env.example. On Webslice the build writes .env from .webslice/env.production instead, so a deploy can never inherit your local values. Anything set under Env Vars in the Console beats both, because Laravel never overwrites a variable that is already set.
So the order is Console, then .webslice/env.production. .env.example is only ever read on your own machine.
Static caching is off locally
STATAMIC_STATIC_CACHING_STRATEGY is null locally and full in production. With it on you would edit a page, reload, and be handed the copy you rendered a minute ago, which makes writing anything miserable.
In production it is what you want: each page is written to public/static and returned by the web server without starting PHP. If you do switch it on locally to test something, run php please static:clear when you are done.
Assets move to shared storage
Locally public/assets is a normal folder. On Webslice the build copies whatever is committed into /mnt/data/website/shared/public/assets, then replaces public/assets with a symlink to it, so uploads made in the Control Panel survive the next deploy.
That has a consequence. Locally, deleting a file from the repository removes it from the site. In production it does not, because shared storage still has its copy. Delete it in the Control Panel or over SFTP.
The application key is generated for you
Locally composer setup makes one. On Webslice, if you have not set APP_KEY in the Console, the first deploy generates one and keeps it in shared storage so every later deploy reuses it. That is why you can deploy this without setting anything up first.
Your local key and your production key are different, and should be. They encrypt different sessions.
The Stache watcher
STATAMIC_STACHE_WATCHER is on locally so file edits appear straight away, and off in production where content only changes on deploy. Left on, it would scan the filesystem on every request looking for changes that cannot happen.
Putting it live
The steps are in the repository's README.md, starting with making your own copy. Your site's URL is the only value you have to supply.