Set Up Your App Settings on Tanzahost

Your app is live, but you are not sure where its code comes from, which branch goes out, or what survives a deploy. In this post you walk through the Settings tab once and finish with build and run, scaling, access and email set the way you want them.

Nadia runs a small online shop. She wants every push to her main branch to go live, and she wants her uploads folder to keep its files between deploys. She does all of it in Settings.

What you need before you start

• An app in a project on Tanzahost, already running, so its Settings tab is there.

• The address your app's code comes from, and the branch you deploy from.

• The language your app is written in and the version you want it to run.

• The start command for your app.

• The address you want checked as the health address.

• Any folders that must keep their files when a new version goes live.

The steps

Open the Settings tab

The Settings tab is one column of settings, in sections. Links to each section sit at the top of the column, so you can jump straight to the part you need. The sections are Build and run, Scaling, Access, Email, Maintenance and Danger zone.

If you opened the Settings tab of a site, its PHP settings come first, then the same sections after them.

Set where the code comes from and when it deploys

In Build and run, set where the code comes from and its branch. Then set Deploy every push: on or off at any time, and which branch it applies to. Nadia turns it on and points it at main, so every push she makes goes live.

Deploy every push is a switch. A switch saves at once, and says so. There is no form to send after you flip it.

Set the language, the start command and the health address

Still in Build and run: the language and its version, the start command, and the health address. The start command is what your app is launched with. The health address is the address you want checked to see that the app is answering.

Set the command before going live and the folders that stay

Also in Build and run: the command before going live, and the folders kept between deploys. Nadia adds her uploads folder to that list, so the files her customers upload are still there after the next deploy.

The same settings can live in the tanzahost.json file in your code. If you would rather keep them there, see the settings file and pick one place, not both.

Set its limits, its copies and whether it sleeps

In Scaling, you set its limits, its copies, and whether it sleeps. Limits are what the app is allowed to use. Copies is how many copies run at once. Sleeping is whether it stops when nobody is using it.

Set access, the deploy address and the hidden paths

In Access, you set SFTP and SSH, the deploy address, protection and speed, and the paths hidden from visitors. The paths hidden from visitors keep files out of reach of anyone browsing your site, while your app can still use them.

Turn on sending email

In Email, you set sending email from the app. This is the section for any mail the app sends out, like order confirmations from Nadia's shop.

Put maintenance in place

Maintenance holds Maintenance mode. Open it when you need the app to show something else while you work on it.

Use the Danger zone only when you mean it

Danger zone has three actions: move it to another project, stop it, or delete it. None of these are part of a normal setup, so leave this section alone until you actually need one of them.

Save your changes

Saving works in two ways, and which one applies depends on the control:

• A switch saves at once, and says so.

• A form has one Save, which you can choose once you've changed something.

So: flip a switch and it is done. Edit a field in a form and then click the one Save on that form. Nadia flips Deploy every push and it is saved straight away, then edits her branch and start command in the form and clicks Save once.

Check that it worked

• Reload the Settings tab and read each value back. The branch, language, version and start command should read the way you set them.

• Look at the switches. Each one says it saved when you flipped it.

• Look at the Save button on a form. If it can be chosen again, the form still holds a change you have not saved. If you cannot choose it, there is nothing left to send.

• Push to the branch named in Deploy every push and open the deploy address from Access. You should see the new version of the app.

• Put one file in a folder listed under the folders kept between deploys, deploy again, and check the file is still there.

The mistakes people make, and how to fix each

Editing a form and expecting each field to save on its own. A form has one Save. Change what you need, then click Save once.

Looking for a Save button after flipping a switch. A switch saves at once, and says so. There is nothing to send.

Clicking Save with nothing changed. You can choose Save once you've changed something. Change a value first, or leave the form as it is.

Setting the same thing in two places. The same settings can live in tanzahost.json. Pick one place and keep it there, as the settings file explains.

Turning Deploy every push on for the wrong branch. The switch saves at once, so check which branch it points at right after you flip it. You can turn it off at any time.

Losing uploads between deploys. Add the folder to the folders kept between deploys in Build and run, then click Save.

Letting visitors reach a file you meant to hide. Add the path to the paths hidden from visitors in Access.

Writing the wrong health address. The health address sits in Build and run. Write the address your app answers on, not the page you happen to have open.

Next

• Keep the same settings in your code: the settings file.

• Decide what the app may use: limits.

• Let it stop when nobody is using it: sleeping.

• Get files in and out by hand: SFTP and SSH.

• Turn on mail from the app: sending email.

• Show something else while you work: Maintenance mode.

• Move the app to another project: moving an app.