<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Deployment on nidomiro</title><link>https://nidomiro.de/tags/deployment/</link><description>Recent content in Deployment on nidomiro</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 14 Mar 2025 10:43:41 +0100</lastBuildDate><atom:link href="https://nidomiro.de/tags/deployment/index.xml" rel="self" type="application/rss+xml"/><item><title>More secure deployments via ssh</title><link>https://nidomiro.de/code/more-secure-deployments-via-ssh/</link><pubDate>Fri, 21 Aug 2020 12:00:00 +0000</pubDate><guid>https://nidomiro.de/code/more-secure-deployments-via-ssh/</guid><description>&lt;p>If we deploy an application automatically we have to grant the CI
(Continuous Integration) access to the server. Common practice is to do
that via a GitLab Runner or an ssh account on the server.&lt;/p>
&lt;p>Personally I would not recommend using a GitLab Runner for deployments,
because you have to maintain it. Another potential issue is, that you
normally register runners for your whole GitLab instance or groups. That
results in a scenario in which everyone can use that runner and
accidentally (or not) destroy, for example, your production server. To
avoid that you have to register the GitLab Runner in the Project it
belongs to only. But even then your production server can be misused as
a build worker and therefore create performance issues.&lt;/p></description></item></channel></rss>