Skip to content
TurguzDocsTürkçeOpen the panel

Services

Deploying your project

Build and deploy a project on Turguz from your Git repository or your computer. Turguz recognises the project's language, checks what it needs and gives you the site's address.

Turguz recognises your project's language and builds it for you; .NET, Clojure, Go, Java, Node.js, PHP, Python, Ruby and Scala projects are built this way. For Deno, Rust and Leptos projects Turguz prepares a Dockerfile; a project whose language isn't recognised, or that needs system packages, can also be built with its own Dockerfile (see below). Every deployed project runs in an environment; environments, deployments and settings are covered on the Environments and deployments page.

To create and deploy a project, you need the «Kiracı yöneticisi» (Tenant admin) or «Geliştirici» (Developer) role.

#Connecting the source

#Git repository

On the Git bağlantıları (Git connections) tab of the Projects page, connect your account on the server where your repository is hosted:

  • github.com: «GitHub ile bağlan» (Connect with GitHub), then «Turguz'u GitHub'a kur» (Install Turguz on GitHub). You choose on GitHub which repositories Turguz can access; Turguz asks only for read permission.
  • ciblab.dev: «ciblab.dev hesabını bağla» (Connect your ciblab.dev account).

You can remove the connection from the same tab with «Bağlantıyı kes» (Disconnect); your live sites keep running.

Git submodules of repositories on GitHub are fetched for the build. A submodule that can't be reached is skipped, the build continues and the build log tells you which one was not fetched. Submodules are not fetched from ciblab.dev repositories.

#By uploading files

If you don't use Git, you upload the project as an archive (.zip, .tar.gz, .tar.bz2, .tar.xz or .tar) or as a folder. Drag the folder onto the panel or pick it with «Klasör seç» (Choose folder); the panel turns it into an archive itself and leaves out folders the build doesn't need, such as node_modules and .git. The compressed archive can be at most 100 MB (your platform administrator can change this limit), its extracted contents at most 512 MB, and it can contain at most 50,000 files. Don't put node_modules, .git or build output in the archive.

If the archive contains a .env file, setup copies its values into environment variables and removes the file from the live app.

#Creating the project

On the Projects page, press «+ Proje» (+ Project):

  • «Ad» (Name): the project's name.
  • Source: «GitHub», «ciblab.dev» or «Dosya yükle» (Upload files).
  • The repository and «Varsayılan dal» (Default branch). If you leave the branch empty, the repository's own default branch is used.
  • «Kimler görür?» (Who can see it?): «Kiracıdaki herkes» (Everyone in the tenant) or «Yalnız seçtiğim üyeler» (Only members I choose).

Then press «Proje oluştur» (Create project).

#Set up and deploy

If the project has no environment yet, the project page shows the Projenizi kurun (Set up your project) card. In order, the card checks your quota, creates the environment, sets up the database if needed, sets the site's address, requests internet access if needed, and then runs the first build and deploys it.

Before it starts, the card looks at your project's files and shows what it needs:

  • for a project that uses PostgreSQL, whether a database should be set up,
  • missing environment variables and secret keys that Turguz can generate for you,
  • a variable that expects the site's address,
  • the need to reach the internet (this goes to your administrator for approval).

After acknowledging the warnings with «Anladım» (Got it), press «Kur ve dağıt» (Set up and deploy). If the panel sees that the project will most likely not start, it tells you so; to try anyway, there is a «Yine de kur ve dağıt» (Set up and deploy anyway) option.

Setup proceeds step by step and shows the site's address when it finishes. If it stops at a step, press «Kaldığı yerden devam et» (Continue where it left off). «Vazgeç» (Cancel) abandons setup but does not delete what has been created up to that point. If you want to configure everything yourself, use the «Elle kurmak istiyorum» (I want to set it up manually) option.

#Readiness report

The Hazırlık (Readiness) section on the environment's Genel bakış (Overview) tab looks at the project's files and lists what it needs regarding the database, variables, internet and files. The needs appear in three groups: what you need to do, what is ready, and information. Click a row to see the reason and the file behind it. Save a setting suggestion with «Değiştir» (Change) on the row. For variables, «Değişkenlerde aç →» (Open in Variables →) takes you to the Variables tab. Settings your code reads but you have not defined are listed there too; add one with «Tanımla» (Define). After changing the project, press «Yenile» (Refresh) to have it check again.

#Port and address

Your app must listen on the port in the PORT variable and on all network interfaces (0.0.0.0). If it listens only on localhost or 127.0.0.1, traffic won't reach it.

Turguz fills the PORT variable with the environment's app port. The default port is 80; you change it in the «Uygulama portu» (App port) field in the Derleme ve çalıştırma (Build and run) section of the environment's Ayarlar (Settings) tab. Don't write a value into the PORT variable yourself.

text
Node.js   app.listen(process.env.PORT || 8080, "0.0.0.0")
Python    gunicorn app:app --bind 0.0.0.0:$PORT
          uvicorn main:app --host 0.0.0.0 --port $PORT
Go        http.ListenAndServe(":"+os.Getenv("PORT"), nil)
Spring    server.port=${PORT:8080}

#PHP projects

Turguz builds PHP projects laid out with composer.json, composer.lock and public/index.php (Laravel, Symfony, CodeIgniter 4 and Slim, for example). The site is served only from the public/ folder; source files, vendor/ and .env are never exposed. The PHP version is chosen from the require.php line in the project's composer.json. The framework's temporary-file and log folders (storage/, var/, writable/ and the like) are writable at run time; their contents are reset with every new release, so keep data that must persist in the database. Symfony projects are built and run with APP_ENV=prod. A Laravel project with a linked database gets DB_CONNECTION=pgsql and DB_URL; without a database, sessions and temporary data are kept in files and queued jobs run right away. Log lines PHP writes to standard error show up in the app's log, and Laravel's log is sent there too (LOG_CHANNEL=stderr). If you set any of these variables yourself, your value is used. Plain PHP sites served from the project root and apps that need MySQL, such as WordPress, can't be deployed; the readiness report tells you what to do in that case.

#Apps that use a browser

If your Python or Node app uses Playwright, Puppeteer or Selenium, Turguz adds Chromium to the app during the build. You do not need to change your code or download a browser, and the browser needs no internet while the app runs. The readiness report tells you this before you publish.

  • The browser is added for production dependencies. A package installed only for tests (devDependencies) does not make the app larger.
  • Only headless Chromium is available: Firefox, WebKit, headed mode and video recording do not work.
  • puppeteer-core and pyppeteer need the browser path from your code: write executablePath: process.env.PUPPETEER_EXECUTABLE_PATH in Node, executablePath=os.environ["CHROME_BIN"] in Python.
  • The browser runs in its own sandbox; a --no-sandbox flag in your code is ignored.
  • If the app visits outside sites, request internet access for the environment.
  • The Small size is enough for one tab. For several tabs at once or very long page screenshots, choose Medium or larger.
  • You can run a browser job with no website as a «Arka plan işi» from the same build.

#Building with your own Dockerfile

Turguz recognizes your project's language and builds it itself. If your language isn't recognized (Elixir, for example), your PHP project doesn't follow the expected layout or your app needs system packages (ffmpeg, for example), you can have the project built with its own Dockerfile: set the «Derleme yöntemi» (Build method) field in the Derleme ve çalıştırma (Build and run) section of the environment's Ayarlar (Settings) tab to Dockerfile. The readiness report suggests this for suitable projects, but a suggestion isn't required: if the app folder has a Dockerfile you can choose it in this field even when the report doesn't suggest it. If the report suggests it, the setup card also offers «Projenin Dockerfile'ıyla derle» (Build with the project's Dockerfile) when you set up the project. In an environment with several apps the method is chosen per app: «Uygulamaları düzenle» (Edit apps) in the Uygulamalar (Apps) section, the row's «Derleme» (Build) field.

  • Deno, Rust and Leptos projects don't need a Dockerfile of their own: Turguz prepares one from the project's contents. The readiness report suggests it; choose «Turguz'un hazırladığı Dockerfile» (Dockerfile prepared by Turguz) in the «Derleme yöntemi» (Build method) field, and «Dockerfile'ı gör» (View the Dockerfile) shows the prepared file. This Dockerfile isn't written to your repository; it is used only during the build. It isn't suggested in installations without an internet connection.
  • The Dockerfile must be at the root of the app folder.
  • The app starts with the Dockerfile's CMD line; the «Başlatma komutu» (Start command) field isn't used.
  • Set «Uygulama portu» (App port) to the port in the Dockerfile's EXPOSE line.
  • Environment variables reach the Dockerfile as ARGs. Variables marked secret arrive as secrets instead of ARGs: read them with RUN --mount=type=secret,id=NAME,env=NAME command; the value isn't written into the image.
  • If «Derlemede veritabanı» (Database during build) is on, the database connection variables also arrive as ARGs (for example ARG DATABASE_URL). That connection is read-only and closes when the build ends.
  • The build runs on an isolated machine: RUN --security=insecure and RUN --network=host aren't available, and the # syntax= line is ignored.
  • If the pip of the Python in your Dockerfile is old, some package indexes (PyTorch, for example) can't be read and the build fails. If you turn on «Eski pip'i derlemede güncelle» (Update an old pip during the build) under «Derleme yöntemi», Turguz adds a line that updates pip at the start of every stage that runs pip install; your repository isn't touched, and the build log shows the added line.
  • On installations without an internet connection, .NET (NuGet), Java (Maven, Gradle), Rust (Cargo) and Alpine (apk) packages are downloaded only from the site's package mirror. Add this line to the same stage, before the step that downloads packages (such as dotnet restore, mvn package, gradle build, cargo build or apk add): RUN sh -c "${TURGUZ_AYNA_KUR:-}". On sites with internet access the line does nothing, so the same Dockerfile works everywhere.

#Functions in the api/ folder

If your project has an api/ folder and doesn't start its own server (no start script), Turguz publishes each file in the folder as an endpoint: api/hello.ts → /api/hello, api/products/index.js → /api/products. Static files at the root are served too.

  • Files can be JavaScript (.js, .mjs, .cjs) or TypeScript (.ts, .mts, .cts); you don't need a build step for TypeScript.
  • Dynamic paths: api/products/[id].ts → /api/products/42; api/docs/[...path].ts matches one or more segments. The values arrive in req.query. A static file matching the same path takes precedence.
  • Files and folders starting with _ are helpers, not endpoints.
  • There are two handler styles: - export default function handler(req, res): req.query, req.body, req.cookies; res.status(), res.json(), res.send(). - A handler named after the method: export function GET(request) { return Response.json({ ... }) }. A method that isn't exported returns 405.

#The site's address

Once the environment is live, the site's address appears in the environment's header. Clicking the address opens the site; the icon next to it copies the address.

#While the site is starting or unavailable

Whenever your app isn't running, the visitor sees Turguz's opening page at your site's address. The page is shown in Turkish or English, depending on the visitor's language:

  • "The site is starting": when the site is first deployed, while a new version is going live, on a restart, or while a stopped environment is being started. The steps are shown live; when the site is ready, the page switches to the site by itself.
  • "This site is paused": when the environment is stopped. The page reminds the site's owner of «Başlat» (Start) in the panel; once the environment is started, it switches to the site by itself.
  • "This site is temporarily unavailable": when the tenant is suspended. The reason is not shown to the visitor.
  • "The site isn't responding right now": when your app has crashed. When the site is back up, the page refreshes by itself.

Search engines see this page as "temporarily down" and don't index it; your site's existing entry in their index is kept.

#Files and persistent data

The app's disk is reset with every new version. Images and documents uploaded by users are lost; keep them in a database, in S3-compatible object storage or on the app's persistent disk (if it is enabled for your tenant; Environment size). For databases, see the Database page.

#Reaching the internet

By default, a live app can't reach the internet. If it needs to reach an external service, a payment system or remote images, press «İnternet erişimi iste» (Request internet access) in the Alan adı ve erişim (Domain and access) section of the environment's Ayarlar (Settings) tab and give your reason; your administrator approves it. The access that is opened covers web ports and sending e-mail (ports 587 and 465); port number 25 is closed, so use 587 in your e-mail settings.

#"Deploy to Turguz" link

If you put the following line in your repository's README, anyone who clicks the link gets the project creation dialog after signing in, with the repository address already filled in. That person creates the project themselves.

markdown
[![Deploy to Turguz](https://turguz.app/turguza-dagit.svg)](https://turguz.app/yeni-proje?depo=https://github.com/<account>/<repo>)

Only the https address of a github.com or ciblab.dev repository is accepted.

#Deleting a project

You delete a single project from the Tehlikeli bölge (Danger zone) on the project's page. Two windows ask in turn: first one lists the environments, databases and other data attached to the environments that are deleted with the project, then the other asks for final confirmation.

To delete several projects at once, tick the boxes on their rows in the Projects list and press «Sil» (Delete) in the bar that appears above the list. The window lists every project you selected, together with the environments and databases that will be deleted; to confirm, you type the number of projects you selected. Projects are deleted one after another and this can take a few minutes; it carries on even if you leave the page. Projects that are already being deleted, or that have work running in one of their environments (a deployment, a command, a database operation), can't be selected. If one of your selected projects can't be deleted at that moment, none of them is deleted; the window tells you why. If one project stops while the deletion is running, the others keep being deleted; the reason for the stopped one is shown on its environment's row. The number of projects you can delete at once is limited; the bar tells you the limit.

Managed databases are deleted together with their data; if you want to keep it, take a backup first. If you're connected to an existing database, only the connection is removed; the database itself is not touched. The tenant's shared database server isn't deleted. Deleting can't be undone.

#Not supported

  • Scheduled jobs that run separately (cron). You can set up a scheduler inside your app and run it as a background job (see Processes without a website).
  • Features that rely on system tools that aren't available at runtime (if you build the project with its own Dockerfile, you can install these tools there; see Building with your own Dockerfile).
  • Large files stored with Git LFS; only their pointers reach the build.
  • MySQL, MongoDB and Redis.
  • Python and Go functions in the api/ folder (JavaScript and TypeScript are supported).
  • Asking the browser to wipe all of a site's data in one response on the platform address. That address sits under a domain shared with other sites, so such a request does not reach visitors. Delete your app's cookies one by one on sign-out.