회사 서버에 직접 설치(온프렘)

인터넷에 올리면 안 되는 사내 도구·대시보드·데이터가 있는 회사를 위한 방식이에요. Docker 서버 한 대부터 Kubernetes, 인터넷이 끊긴 폐쇄망까지 되고, 회사 통합 로그인(OIDC·SAML)도 연동돼요. 기업 기능(구성원·부서·배포 통제·감사 기록)은 그대로예요.

어디서 시작해요?

• 왼쪽 메뉴 「온프렘 설치」(개인) 또는 기업 관리의 「온프렘 설치」(조직 관리자). 회사 이름으로 받고 다른 관리자와 같이 관리하려면 기업 계정 쪽을 써요.
• 먼저 도입 문의 — 설치 파일은 회사 서버에 복사되는 소프트웨어라 누구에게나 열어 두지 않아요. 「온프렘 설치」 화면에서 회사·용도를 적어 도입 문의를 보내면 저희가 확인하고(보통 1영업일) 그 계정에 다운로드·체험·구매를 열어 드려요. 결과는 가입 메일로 알려 드려요.
• 1단계 설치 파일 다운로드 → 2단계 라이선스 받기(체험은 카드 없이 즉시, 구매는 앱 서버 수 × 기간) → 3단계 서버에서 설치. 단계별 그림 가이드는 onpod.ai/onprem에 있어요.

라이선스는 어떻게 넣어요?

• 발급된 라이선스의 「라이선스 보기·복사」로 내용을 복사해, 설치한 회사 onpod 콘솔 → 슈퍼어드민 → 라이선스 카드 → 「라이선스 붙여넣기」에 붙이고 「적용하기」. 서버 재시작 없이 바로 적용돼요.
• 파일로 두고 싶으면 설치 폴더의 license/license.json 에 넣어도 같아요. 둘 다 있으면 만료가 더 늦은 유효한 것이 쓰여요.
• 만료되면 14일 유예 뒤 새 배포·빌드·서버 추가만 잠기고, 이미 배포한 앱은 계속 실행돼요. 갱신은 같은 화면에서 하고, 새 기간은 지금 만료 다음 날부터 이어져요.

가격

앱 서버(호스트) 수 × 기간이에요. 사용자 수·배포 수·트래픽은 세지 않아요. 12개월 결제는 2개월이 무료예요. 정확한 금액은 「온프렘 설치」 구매 카드에서 서버 수와 기간을 고르면 바로 보여요. 카드 결제 대신 별도 계약(견적·세금계산서·계좌이체·다년 계약·설치 지원)도 돼요 — [email protected]로 연락해 주세요.

무엇이 되고, 무엇이 아직 안 돼요?

• 되는 것 — 정적 사이트 · Docker 컨테이너 앱(단일·자동확장·워커, 서버에서 Dockerfile 빌드) · 파일 저장소(S3 호환) · 서비스형 Postgres(onpod db create — 회사가 등록한 Docker 앱 서버 위에 컨테이너로 만들어져요) · 회사 통합 로그인 · 기업 기능(구성원·부서·배포 통제·감사 기록·방문 통계).
• 서비스형 Postgres 의 범위 — 만들기·붙이기(--attach-db)·비밀번호·멈춤/다시 켜기·지우기(컨테이너는 바로, 데이터 볼륨은 7일 뒤)가 돼요. 요금과 크기 상한이 없어요. 자동 백업·복구·크기 변경·연결 풀·IP 허용 목록은 아직 없어요 — 백업은 서버 관리자가 pg_dump 로 회사 백업에 넣어요. Kubernetes 클러스터만 있는 회사는 Docker 서버 1대를 붙여야 DB 를 만들 수 있어요.
• 아직 안 돼요 — GPU 서버 위 앱(설계는 됐지만 실측 전), 여러 서버가 같은 디스크를 쓰는 공유 볼륨(NFS), 고정 발신 IP(사내망에선 해당 없음).

설치 파일을 받기 전에 동의하는 약관은요?

설치 파일은 회사 서버에 복사되는 소프트웨어라, 다운로드·라이선스 발급 전에 온프렘 소프트웨어 라이선스 약관에 한 번 동의해요(라이선스 범위 안에서만 쓰고, 프로그램을 분해·역컴파일·재배포하거나 라이선스 확인을 우회하지 않는다는 내용). 약관이 바뀌면 새 버전에 다시 동의해요.

인프라(서버)는 어떻게 할당돼요? Kubernetes(EKS)가 필요해요?

• 온프렘 onpod은 클라우드 서버를 스스로 빌리지 않아요. 관리자가 add-host.sh로 등록한 Docker 서버나 Helm으로 등록한 Kubernetes 클러스터 위에서만 앱이 실행돼요 — EKS 같은 클라우드 자원은 필요 없어요.
• 직원이 앱을 만들면 등록된 서버들의 빈 슬롯(서버 RAM을 앱 크기 micro·small·medium·large로 나눈 자리)에 배치돼요. 남은 슬롯은 슈퍼어드민 「GPU·CPU 재고」, 서버 상태는 「서버 (하드웨어)」에서 봐요.
• 슬롯이 모자라면 배포가 거절되고, 서버를 한 대 더 붙이거나 노드를 늘리면 돼요.

직원이 무엇을·어디까지 배포할 수 있는지 규칙으로 정할 수 있어요?

• 기업 관리 → 배포 통제 → 배포 규칙에서 정해요: 배포 형태(정적·단일·자동 확장·워커), 앱 최대 크기, GPU 허용·장수·모델, 서비스형 DB 허용·크기·1인당 개수, 기능(파일 저장소·공유 디스크·샌드박스·도메인·서버 빌드·외부 이미지), 이미지 접두어 허용/차단, 1인당 앱 수·복제 수·리전, 그리고 보안팀 규칙 문장.
• 규칙 밖 요청은 배포 시점에 서버가 403으로 막고 이유를 알려줘요. 같은 규칙이 onpod manual 끝에 붙어 직원의 코딩 에이전트가 처음부터 규칙 안에서 제안해요(예: DB 금지면 DB 제안을 빼요).
• 보수적·표준·자유 프리셋으로 시작해 항목을 고치면 돼요. 이미 배포된 앱은 그대로 실행되고 새 배포·업데이트부터 적용돼요.

회사 GitLab·Argo CD와 연동돼요?

• 소스 보관 — 기업 관리 → 연동 → GitLab을 켜면 서버 빌드·정적 배포마다 소스 스냅샷을 <그룹>/<앱이름> 프로젝트에 커밋하고 onpod-<배포ID> 태그를 달아요. 바이브코딩 결과물이 회사 자산으로 남아요. 실패해도 배포는 막지 않아요.
• GitOps 내보내기(Argo CD) — 앱을 만들거나 업데이트할 때마다 Kubernetes 매니페스트(Deployment·Service·Ingress)와 Argo CD Application을 매니페스트 저장소에 커밋해요. 회사 Argo CD에 그 저장소를 등록하면 onpod에서 검증한 앱을 운영 클러스터로 승격할 수 있어요. 환경변수 값은 Git에 싣지 않아요(secretRef 참조만).
• onpod 자체도 Helm 차트라 Argo CD Application으로 설치·운영할 수 있어요.

빌드한 이미지의 취약점도 검사돼요?

• 서버 빌드가 끝나면 번들에 포함된 스캐너(Trivy + 취약점 DB)가 그 이미지를 검사해 CRITICAL·HIGH·MEDIUM·LOW 수와 수정 버전 유무를 남겨요. CLI의 onpod build status와 팟 상세 「취약점 검사」에서 봐요. 폐쇄망에서도 동작해요(DB는 번들과 함께 업데이트).
• 정책은 기업 관리 → 연동 → 이미지 취약점 검사에서 끄기·경고만(기본)·CRITICAL이면 배포 막기 중 골라요. 막기면 CRITICAL이 있는 이미지는 배포·업데이트가 거절되고, 베이스 이미지를 수정 버전으로 업데이트해 다시 빌드하면 돼요.
• 번들 자체의 검사표(SECURITY-SCAN.md)와 SBOM(sbom/*.cdx.json)도 설치 파일 안에 들어 있어요.

직원은 어떻게 배포해요?

하던 대로예요. 회사 onpod 주소에서 CLI를 받아 로그인하고, 코딩 에이전트에게 말하면 에이전트가 회사 onpod인 걸 인식하고 사내 주소로 배포해요.