Services

Environments and deployments

dev, stage and prod environments; automatic release, environment size, variables, the command that runs before release, rolling back and stopping an environment.

Each environment of a project is a separately running copy of it. The environment names are dev, stage and prod; usually dev is for development, stage for testing and prod for the live site. Each environment tracks a branch and has its own variables, address and size.

Environments are listed under their project on the Projects page. When you select an environment, its tabs open: Genel bakış (Overview), Dağıtımlar (Deployments), Günlükler (Logs), Değişkenler (Variables), Veritabanı (Database) and Ayarlar (Settings).

#Creating an environment

Press «Yeni ortam» (New environment) and choose:

• «Ortam» (Environment): dev, stage or prod.
• The size (see the table below) and «Uygulama portu» (App port).
• Optionally, environment variables and Uygulama klasörü ve komutlar (App folder and commands): the app folder if your project is not at the repository root, and build and start commands if needed. When a Dockerfile can be chosen for a new environment, «Derleme yöntemi» (Build method) is here too; choose Dockerfile here, because the dev environment's first deployment starts on its own; see Building with your own Dockerfile.

Then press «Ortam oluştur» (Create environment). The tracked branch is in the «Dal» (Branch) field in the Genel (General) section of the environment's Ayarlar (Settings) tab.

#Automatic release

An environment can build and go live by itself on every push to the branch it tracks. It is on by default in the dev environment; in stage and prod you turn it on with Ayarlar (Settings) › Genel (General) › «Push'ta otomatik yayın» (Automatic release on push). When you turn it on, you are asked to confirm what this means: every change you push to that branch goes live directly, without anyone approving it. While it is off, the environment is updated only with «Dağıt» (Deploy).

#Deploying manually

The «Dağıt» (Deploy) button in the environment's header opens the Yeni dağıtım (New deployment) dialog. If you leave the commit field empty, the branch's latest commit is deployed. If you choose a version that has already been built, it is deployed without being rebuilt.

In projects created by uploading files, the button becomes «Arşiv yükle» (Upload archive). Choose the new archive and press «Yükle ve dağıt» (Upload and deploy). Uploading the same file again does not start a new build.

#Deployments and logs

The Dağıtımlar (Deployments) tab lists every deployment with its status: «Kuyrukta» (Queued), «Yapılıyor» (In progress), «Başarılı» (Succeeded), «Hata» (Error) or «İptal edildi» (Cancelled). A running deployment goes through the build, pre-release command and deploy steps in that order; «İptal et» (Cancel) stops a running deployment.

On the Günlükler (Logs) tab you follow, live, the app's output in «Canlı günlük» (Live log) and the build output in «Derleme günlüğü» (Build log). Secret values don't appear in the logs.

When a new version goes live, the old version stops first; until the new one is up, the site doesn't respond for a short while (what visitors see meanwhile: While the site is starting or unavailable). In environments your platform administrator has set to zero-downtime releases, the old version stays live until the new one is ready. If the build or the pre-release command fails, the live version is not touched.

A failed deployment comes with a short summary that tells you the reason and what to do. Usually there is also a button that takes you to the right place: «Yeniden derle» (Rebuild), «Veritabanı ayarlarına git» (Go to database settings) or «Ortam değişkenlerine git» (Go to environment variables).

#Rolling back

If you're not happy with the live version, use «Geri al» (Roll back) next to an older version on the Dağıtımlar (Deployments) tab to return to that version; the panel asks you to confirm twice. Rolling back brings back the app's version; it does not undo changes made in the database.

If Ayarlar (Settings) › Genel (General) › «Otomatik geri dönüş» (Automatic rollback) is on, the environment returns to the previous version by itself when a new version fails to start, and notes this in the deployment list.

#Environment size

The environment size is the memory and CPU your app can use; it counts against your quota.

The default size is «Küçük» (Small). With the «Özel» (Custom) size, memory can be 256 MB to 64 GB and CPU 1 to 32 vCPU.

Each environment also has a temporary disk: the space the app writes to while it runs. The default is 5 GB and it can be 1 to 20 GB; it counts against your quota and is reset with every new version.

For data that must survive between versions, you can add a persistent disk to an app (if it is enabled for your tenant). A persistent disk can be up to 2 TB; it is added to the app's disk and counts against your quota. It can be grown but not shrunk: if you need a smaller disk, create a new one and move your data. A snapshot of the persistent disk is taken every day. By default snapshots are kept for the last 3 days; a project manager can choose 3, 7 and 14 days or turn snapshots off. Snapshots count against your quota only by the amount they exceed the disk's size. If snapshots push you over your quota, you are warned; if the quota is not raised or space is not freed within 3 days, the oldest snapshots are deleted and the newest snapshot of each disk is kept. If you turn snapshots off, the last snapshot keeps using space and counting against your quota until the disk is deleted. You can roll the disk back to a snapshot's day with «Bu güne dön» (restore to this day): anything written after that point is lost on this disk, and the app stops briefly during the restore. A snapshot of the current state is taken first and kept for at least 7 days; restoring to it undoes the operation.

You change the size in the «Boy» (Size) row on the environment's Ayarlar (Settings) tab.

#Variables

On the Değişkenler (Variables) tab you manage environment variables: you can add them one by one with «+ Değişken ekle» (+ Add variable) or in bulk by pasting .env text, and you can copy them from another environment. An environment can have at most 500 variables; a value can be at most 64 KB long.

• A value marked as secret is not shown in the panel again; to see it, you press «Göster» (Show), and this is recorded.
• «Üret» (Generate) creates a random secret key that your framework asks for (for example AUTH_SECRET).
• Variables whose names start with any of NEXT_PUBLIC_, VITE_, REACT_APP_, NUXT_PUBLIC_, PUBLIC_, EXPO_PUBLIC_, GATSBY_ and VUE_APP_ are written into the code during the build and are visible in the browser. Don't put secrets in them. When their values change, the version is rebuilt.
• The variables of a connected database are provided by Turguz; if you write your own value under the same name, yours takes effect.

#Command that runs before release

Run database migrations (schema changes) once, before the new version goes live. Enter the command in the «Yayından önce çalışacak komut» (Command to run before release) field in the Yayından önce (Before release) section of the environment's Ayarlar (Settings) tab. If the field is empty, the release: line of the Procfile in your repository is used. In an environment with several apps, each app has its own command (see Multiple apps).

If the command fails, the new version does not go live and the old version keeps running. In an environment where «Derlemede veritabanı» (Database during build) is on, the command runs before the build (so the build reads up-to-date tables); if it fails, the build doesn't start. Example commands:

npx prisma migrate deploy
npx drizzle-kit migrate
npx payload migrate
python manage.py migrate --noinput
alembic upgrade head
bin/rails db:migrate
php artisan migrate --force
goose -dir migrations postgres "$DATABASE_URL" up

Don't put database migrations in your app's start script: they would run again on every restart.

#One-off command

«Komut çalıştır» (Run command) in the Diğer işlemler (More actions) menu in the header runs a command once inside the live version (for example npm run seed). The command sees the environment's variables and database connection. Interactive commands don't work; changes made in the database are not undone.

#Rebuilding and restarting

• «Yeniden derle» (Rebuild): builds and deploys the latest commit again (in a project created from files, the latest archive), even if it has not changed. While fixing a build problem, you can have the dependencies installed from scratch.
• «Yeniden başlat» (Restart): restarts the same version without building, with the current variables and database connection. The site doesn't respond for a short while until the app is up.

Both are in the Diğer işlemler (More actions) menu in the header.

#Stopping and starting an environment

«Durdur» (Stop) in the Diğer işlemler (More actions) menu stops the environment: the site doesn't respond, while data and settings stay in place. Code pushed to the branch while it is stopped does not go live. «Başlat» (Start) in the environment's header brings the live version back up with the current settings.

What visitors to a stopped site see: While the site is starting or unavailable.

#Multiple apps

If you have several apps in one repository (for example a separate frontend and backend), you can run up to 3 apps in one environment. Each app can be a web app, a background job or an internal service (see Processes without a website). Such an environment is created during setup with the «Projenizde birden çok uygulama var» (Your project has multiple apps) option; to a single-app environment you add a second process later with «Uygulama ekle» (Add app). Each app has its own folder, path in the address and port; you change these later with «Uygulamaları düzenle» (Edit apps) in the Uygulamalar (Apps) section of the environment's Ayarlar (Settings) tab. Each app has its own size, and their total counts against your quota.

In such an environment each app has its own pre-release command. You write it with the «Yayından önce» (Before release) button on the app's row; the command runs inside that app, with its own variables. If it is empty, the release: line of the Procfile in the app's folder is used. In a release, the command of every app that gets a new version runs before the release; if one fails, no app moves to the new version and the old versions keep running.

#How apps reach each other

In an environment with several apps, Turguz gives each app the internal addresses of the environment's apps in variables. Don't write these addresses by hand; read them from these variables in your code:

• TURGUZ_UYGULAMA_<AD>_URL: the address starting with http://. Web apps and internal services have one.
• TURGUZ_UYGULAMA_<AD>_ADRES: the host:port address without a scheme, for gRPC and TCP clients. Only internal services have one.

<AD> is the app's name in capitals, with hyphens turned into underscores: the address of an internal service named odeme-api is in TURGUZ_UYGULAMA_ODEME_API_ADRES. A background job has no address.

The variables exist while the app runs and in the pre-release command, not during the build. These addresses can be reached only from inside the environment: code running in the browser can't reach them, so the call must come from your app's server side.

#Processes without a website

Run a process that opens no port, such as a queue worker, a bot or an in-app scheduler, as a Background job («Arka plan işi»). Run a service that only the other apps in the environment call (for example gRPC) as an Internal service («İç servis»). You choose the type in the app list. In a single-app environment, the type is in the Build and run section of the environment's Settings tab.

• A Background job does not wait for a port and has no address on the site. The old version stops before the new one starts, so two copies never run at once. If the new version cannot keep running for a few seconds, the previous version is started again.
• An Internal service is not reachable from outside and has no address on the site. The other apps in the environment connect to it with its address inside the environment (see How apps reach each other); the readiness report suggests that address for the variable that expects it. An internal service can't be the site's root or the environment's only app: it needs an app next to it that calls it.
• If the only app of an environment is a background job, the environment has no website and no domain can be bound.

For a second process in the same folder, add an app, pick the other app under «Derleme kaynağı» (Build source) and write its start command. This app is not built separately; it restarts with each new version of the other app. The readiness report points out the worker processes in the project (for example a worker: line in the Procfile) and the sibling apps' addresses.

When you set up the project with «Kur ve dağıt» (Set up and deploy), these processes are suggested under «Arka plan işleri» (Background jobs). A job you tick is set up next to the site, using the site's build and its own command. While a persistent disk is selected, the job is not set up together with it; add it after the setup. If the app itself is a worker that opens no port, the setup screen offers «Arka plan işi olarak kur» (Set up as a background job).