# Start the PullRequest Proxy

At this point, we have configured PullRequest Proxy enough where it can connect to the HackerOne Code application and to your source control provider. You can now go ahead and save the `.env` file you've been editing up until now. You no longer need to be logged in as the `pullrequest` user at this point.

```
exit
```

## Configuring the pullrequest-proxy service

For this step, we are assuming that the application is running on a Linux instance with `systemd` as the init process. These steps can be modified for things like `supervisord` or old-style `init.d`, as well.

First, let's open up a new service file under `multi-user.target.wants`.

```
vim /etc/systemd/system/multi-user.target.wants/pullrequest-proxy.service
```

Now, paste the following in:

```
[Unit]
Description=PullRequest Proxy
Documentation=https://docs.pullrequest.com/on-premise-server/

[Service]
EnvironmentFile=/home/pullrequest/pullrequest_proxy/.env
ExecStart=/home/pullrequest/pullrequest_proxy/launcher.sh
WorkingDirectory=/home/pullrequest/pullrequest_proxy
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=pullrequest-proxy
Restart=always
Type=simple
User=pullrequest

[Install]
WantedBy=multi-user.target
```

If you know what you're doing, you can go ahead and modify any of these options to match how you like your services to run.

{% hint style="warning" %}
The `Restart=always` configuration option is important for the auto-upgrade feature as described later. For this feature, the new proxy binary is installed, and the old process exits. The restart pulls in the new version.
{% endhint %}

The following command should pull this configuration in to your running `systemd` instance.

```
systemctl daemon-reload
```

Now, go ahead and enable the service to start automatically on boot and start it.

```
systemctl enable pullrequest-proxy
systemctl start pullrequest-proxy
```

To check on the status, run the following:

```
systemctl status pullrequest-proxy
```

To stop or restart the service, the `stop` and `restart` commands can be used, respectively.

## Configuring Logs

In the previous section, we configured the PullRequest Proxy service to run and started it. However, the configuration itself outputs logs to the running syslog service. Normally, these logs will be output to the `/var/log/messages` file. In order to output these logs to a different file, go ahead and open up a new configuration file under `/etc/rsyslog.d`.

```
vim /etc/rsyslog.d/pullrequest-proxy.conf
```

Put the following in that file:

```
if $programname == 'pullrequest-proxy' then /var/log/pullrequest-proxy.log
& stop
```

Now, restart `rsyslog` to pull in the new configuration:

```
systemctl restart rsyslog
```

Note: We expect `rsyslog` to be present for log forwarding, but on some newer Amazon Linux or minimal distributions, `rsyslog` may not be installed by default. In this case, `rsyslog` would need to installed manually using their package manager:

```
sudo yum install rsyslog
sudo systemctl enable rsyslog
sudo systemctl start rsyslog

```

Alternatively, you should be able to see logs without `syslog`:

```
sudo journalctl -u pullrequest-proxy.service
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.pullrequest.com/on-premise-server/start-the-pullrequest-proxy.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.