Go

나이트로쉽은 go.mod로 Go 프로젝트를 감지합니다. 관리형 프리셋은 모듈을 다운로드하고 정적으로 링크된 서버 바이너리를 만듭니다. 동적 페이지·API는 컴퓨트에서, public/ 폴더가 있으면 그 안의 정적 파일은 CDN에서 제공합니다.

배포하기제목 링크 복사

curl -fsSL https://nitroship.co/install.sh | bash
ntro login

컴퓨트 리전은 기본값이 없으므로 꼭 정하세요. 배포 루트에서 Go를 직접 선택합니다.

{
  "build": {"framework": "go"},
  "compute": {"regions": ["kr-icn"]}
}

ntro apps create my-go-app
ntro deploy . --prod

이 프리셋은 호스팅 빌더에서만 빌드할 수 있습니다. 배포 명령에 --local이 있다면 빼세요. 배포 후 CLI가 보여 준 주소에서 서버 경로와 정적 파일을 각각 열어 보세요.

빌드와 실행 패키지제목 링크 복사

go.mod와 go.sum을 커밋하세요. 툴체인 버전은 go.mod의 go 지시문에서 읽고, 없으면 .tool-versions를 확인합니다. 생성된 빌드는 선언한 버전과 가장 가까운 지원 툴체인·베이스 버전을 고정해서 쓰고, 선언이 없으면 안정 버전을 기본으로 씁니다.

프리셋은 배포 루트의 package main을 먼저 선택합니다. 루트에 없으면 cmd/* 아래에 main 패키지가 정확히 하나 있어야 합니다. 라이브러리 전용 모듈이나 여러 cmd 서버 중 하나는 자동으로 고를 수 없습니다. 가능하면 서버 프로젝트 루트를 배포하거나, 직접 만든 Dockerfile로 실행할 패키지를 지정하세요.

관리형 빌드는 정적으로 링크된 바이너리를 만듭니다. CGO, 네이티브 공유 라이브러리, 추가 빌드 도구가 필요한 프로젝트는 직접 만든 Dockerfile을 쓰세요.

관리형 포트에서 요청 받기제목 링크 복사

앱 코드에서 직접 **0.0.0.0:$PORT**로 요청을 받아야 합니다. 프리셋은 임의의 Go 서버 코드를 바꿀 수 없습니다. PORT가 없으면 3000을 사용하세요. 다른 포트를 하드코딩하거나 localhost에만 바인딩하지 마세요.

port := os.Getenv("PORT")
if port == "" {
    port = "3000"
}
log.Fatal(http.ListenAndServe("0.0.0.0:"+port, handler))

handler에는 앱에서 사용하는 핸들러를 넣고 net/http, os, log를 임포트하세요.

정적 파일제목 링크 복사

public/이 있으면 생성된 이미지의 /app/public에 포함하고, 공개 파일을 /nitroship/static에 모읍니다. 빌더는 서버를 시작하기 전에 파일을 자동으로 CDN 루트에 추출합니다. public/logo.svg는 /logo.svg로 제공됩니다. .go 파일을 포함한 서버 소스는 공개하면 안 됩니다.

public/이 없으면 CDN 정적 출력도 없으며 모든 요청을 컴퓨트의 Go 서버가 처리합니다. 바이너리에 임베드한 파일은 CDN으로 자동 추출하지 않습니다. 다른 정적 파일 구조가 필요하면 공개 폴더를 만들거나 직접 만든 Dockerfile을 쓰세요.

환경 변수와 런타임 제한제목 링크 복사

비밀 값과 앱·DB 설정은 환경 변수로 등록하세요. DATABASE_URL은 관례적인 이름일 뿐이며 앱에서 직접 읽어야 합니다. 영구 데이터는 외부 DB에 저장하세요.

생성된 이미지는 루트 권한 없이 실행됩니다. 인스턴스 파일시스템은 임시 공간입니다. /tmp에는 임시 파일만 쓰세요. 업로드는 이미지나 public/ 대신 S3 같은 오브젝트 스토리지에 저장하세요.

나이트로쉽은 마이그레이션, 큐 워커, 스케줄러를 자동으로 실행하지 않습니다. 프로젝트의 마이그레이션 명령은 CI나 내 컴퓨터에서 외부 DB를 대상으로 실행하고, 워커는 별도로 실행하세요. 정기 HTTP 작업은 앱 안의 스케줄러 대신 Cron 작업을 사용하세요.

프레임워크 선택과 직접 만든 Dockerfile제목 링크 복사

build.framework: "go"는 Go를 직접 선택하며 자동으로 찾은 Dockerfile보다 우선합니다. build.dockerfile과는 함께 쓸 수 없습니다.

프레임워크를 직접 지정하지 않았을 때의 감지 순서는 빌드 방식 선택에 있습니다. CGO, 여러 바이너리, 시스템 라이브러리, 별도 빌드 단계가 필요하면 build.framework를 빼고 직접 만든 Dockerfile을 쓰세요.